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FOREWORD 


This  study  was  performed  for  the  United  States  Air  Force  Space  and 
Missile  Systems  Organization  (SAMSO)  in  accordance  with  the  state- 
ment of  work  for  the  DOD  Space  Transportation  System  CCDS  Study. 

It  was  performed  during  the  period  of  1 February  to  30  October  T974 
under  contract  F04701-74-C-0260. 

The  complete  set  of  volumes  comprising  this  report  includes: 

Volume  I - Study  Summary 

Volume  II  - System  Requirements  Analysis  Definition 
Volume  III  - Command  and  Control  Data  System  Concept  Development 
Volume  IV  - AFSCF/Shuttle  Mission  Control  Center  Requirements 
Analysis 

Volume  V - DOD  Shuttle  Mission  Simulator  Requirements  Analysis 
and  Resource  Acquisition  Schedules 
Volume  VI  - Secure  Data  and  Equipment  Handling 

This  study  was  performed  under  the  direction  of  DOD/SAMSO.  Aero- 
space Corporation  provided  assistance  to  SAMSO.  This  study  was  per- 
formed by  Philco-Ford' s Western  Development  Laboratories  Division, 
Philco  Houston  Operation  with  key  participation  of  personnel  from 
Philco-Ford's  Satellite  Control  Facility  Operation  at  Palo  Alto. 


D.  k.  Dorman,  USAF  Study  Manager 
Philco-Ford  Corporation 


This  final  report  has  been  reviewed  and  is  approved.  Readers  are 
cautioned  that  the  material  presented  herein  represents  the  find- 
ings and  conclusions  of  the  Philco-Ford  Study  Group  and  does  not 
necessarily  define  a DOD/SAMSO  position,  policy,  or  decision. 
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tndemutn,  USAF  Study  Monitor 
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PREFACE 


BACKGROUND 

The  Command  and  Control  Data  System  (CCDS)  Study,  in  previous 
tasks,  analyzed  the  Space  Transportation  System  (STS)  operations 
in  order  to  develop  a Department  of  Defense  (DOD)  CCDS  concept  to 
support  all  STS  operations  phases.  CCDS  is  a collective  term 
since  it  comprises  the  ground-based  data  systems  and  their  inter- 
and  intra-system  communications  required  for  support  of  the  DOD 
STS.  The  CCDS  concept  developed  comprised  seven  functional  con- 
trol elements:  six  primarily  to  support  turnaround  and  launch 

operations  and  one  to  exercise  overall  mission  control  and  to  sup- 
port operations  from  liftoff  through  rollout.  These  are  the  Turn- 
around Control,  Launch  Control,  Range,  Payload  Checkout  Control, 
Operations  Management  Control,  and  Central  Data  Elements  for 
support  of  turnaround  and  launch,  and  for  the  flight  operations 
and  mission  management,  a Mission  Control  Element. 

The  CCDS  concept  developed  is  neither  a single  nor  a totally  new 
system.  Much  of  the  CCDS  currently  exists  in  the  USAF  Satellite 
Control  Facility  (SCF)  and  the  Vandenberg  Air  Force  Base  (VAFB) 
data  and  communications  systems.  NASA-operated  systems  and  facil- 
ities are  to  be  utilized  where  possible  to  avoid  expensive  duplica- 
tions, e.g.,  mission  planning  systems  or  optional  use  of  the 
Tracking  and  Data  Relay  Satellite  (TDRS)  for  contingency  reaction. 
NASA  systems  for  this  study  were  considered  external  to  the  DOD 
CCDS.  In  applications  requiring  new  equipment,  it  is  expected 
that  NASA-developed  systems  will  be  installed  in  DOD  facilities  to 
the  maximum  extent  possible  (e.g..  Launch  Processing  System). 

The  DOD  CCDS  was  considered  a functional  entity  for  purposes  of 
this  study  to  ensure  the  compatibility  of  its  several  elements  by 
developing  its  functional  requirements  as  an  integrated  system. 

This  will  permit  subsequent  integration  of  its  elements  to  be  ac- 
complished efficiently  and  effectively,  and  will  ensure  complete- 
ness of  the  total  STS  Ground  Support  System  concept. 

Subsequent  to  the  start  of  this  study,  a change  in  the  work  to  be 
done  was  directed  by  the  Air  Force  which  modified  Tasks  IV  and  V. 
Task  IV  was  modified  to  delete  the  subtask  to  define  a Shuttle  Mis- 
sion Control  Center  (SMCC),  which  is  part  of  the  Mission  Control 
Element  (MCE).  It  was  replaced  with  a subtask  to  define  the  Air 
Force  Satellite  Control  Facility  (AFSCF)  and  SMCC  requirements 


and  a subtask  to  conduct  the  necessary  analysis  to  define  the  DOD 
Shu' tie  Mission  Simulator  (SMS)  capabilities  required.  Documenta- 
tir  i resulting  from  this  task  is  the  Orbital  Requirements  Document 
(ORD)  hhich  defines  the  AFSCF/SMCC  requirements  to  support  the  STS 
operation  and  volumes  IV  and  V of  this  report.  The  ORD  is  pub- 
lished separately  and  comprises  the  ORD  for  support  of  the  Orbiter, 
external  tank  (ET),  and  solid  rocket  boosters  (SRB's).  A sample 
annex  for  the  ORD  defining  the  requirements  levied  on  the  AFSCF 
by  the  interim  upper  stage  (IUS)  is  contained  in  Part  2 of  this 
volume.  Because  of  the  lack  of  detail  available  on  the  IUS,  this 
sample  annex  is  a guide  only.  It  is  not  a vehicle  levying  require- 
ments on  the  SCF.  Figure  1 illustrates  the  relationship  of  this 
task  to  the  other  tasks  of  the  DOD  STS  CCDS  Study. 

This  volume,  in  addition  to  the  IUS  sample  annex  to  the  ORD,  pro- 
vides backup  information,  rationale,  and/or  qualification  to  mate- 
rial contained  in  the  ORD. 


TASK  OBJECTIVES 

The  task  objectives  defined  in  this  volume  are: 

A.  Make  a preliminary  determination  of  the  operating  positions 
required  within  the  SMCC. 

B.  Determine  the  functions  to  be  performed  at,  and  the  infor- 
mation, control,  and  communication  requirements  of,  each 
operating  position. 

C. .  Develop  a sample  annex  to  the  ORD  detailing,  to  the  extent 

possible  with  current  IUS  program  definition,  the  support 
requirements  levied  on  the  USAF  SCF  by  the  IUS. 


ORGANIZATION 

This  volume  is  presented  in  two  parts.  Part  1 presents  the  SMCC/ 
AFSCF  requirements  analysis  results  that  are  not  items  for  the  ORD. 
Section  2 includes  an  estimate  of  the  operating  positions  required 
within  the  SMCC  to  conduct  STS  operations  together  with  their  infor- 
mation, control,  and  communication  requirements.  Section  3 discusses 


u 


IV 


Figure  1 Task  Interrelationships 


rationale  for  certain  ORD  requirements,  reasons  for  some  require- 
ments being  listed  as  TBD  (to  be  determined),  and  discussions  of 
potential  SMCC  features  considered  desirable  but  not  mandatory. 

Part  2 presents  the  sample  annex  for  the  Space  Shuttle  Vehicle 
ORD  containing  the  IUS  requirements  for  SCF  support.  This  is 
based  on  the  level  of  detail  available  at  this  time.  Because  of 
the  lack  of  definition  of  the  IUS,  the  annex  is  for  information 
only. 

Separate  tables  of  contents  for  Parts  1 and  2 are  provided  preced 
ing  the  text  in  Part  1 and  as  paragraph  1.5  of  Part  2. 
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SECTION  1 


INTRODUCTION 


A major  output  of  Task  IV  of  the  CCDS  study  is  the  STS  Orbital  Re 
quiremente  Document  with  Annex  1 1 IUS  ORD , which  has  been  pub- 
lished separately  as  PH0-TR584,  14  September  1974.  The  purpose 
of  part  2 of  this  TOR  is  to  supplement  the  ORD  by: 


• Discussing  topics  that  influence  the  ORD  but  are  not  topics 
within  it  (e.g.,  estimate  of  SMCC  operating  position  require- 
ments) 

• Explaining  rationale  or  considerations  for  certain  items 
within  the  ORD  that  are  TBD. 

• Discussing  considerations  affecting  implementation  of  Con- 
trol, Display,  Data  Processing,  and  SMCC  interfaces. 


SECTION  2 


SMCC  REQUIREMENTS 


STS  flight  operations  were  reviewed  to  determine  the  ground  func- 
tions required  of  the  SMCC.  Using  as  a baseline  the  functional 
organization  contained  in  DOD  STS  Operations  Concept  Document 
(Draft),  dated  6 August  1974,  the  SMCC  support  functions  were 
assigned  to  one  or  more  of  the  functional  groups  described  in 
that  document.  If  additional  functional  groups  were  required, 
such  groups  were  added.  Analysis  of  the  functions  assigned  was 
then  accomplished  to  determine  if  any  functional  groups  could  be 
combined  and  to  recommend  the  number  of  operating  positions  re- 
quired within  each  group. 

This  section  presents  the  results  of  those  analyses. 

2.1  OPERATING  POSITIONS 

2.1.1  General.  This  paragraph  presents  the  recommended  SMCC  op- 

erating positions  and  for  each  position,  it  defines  the  functions 
to  be  performed  and  the  information,  control,  and  voice  communica- 
tion requirements.  In  defining  these  requirements  two  functional 
SMCC  groups  are  considered:  Orbiter  and  IUS. 

Figure  2-1  shows  the  positions  and  organization  of  the  SMCC  in 
support  of  the  Orbiter  and  IUS.  Tables  2-1  and  2-2  list  the  rec- 
ommended positions,  define  the  activity  period  (nominal  and  con- 
tingency) for  each  operating  position,  and  identify  the  type  of 
console  anticipated  for  each  position  (i.e.,  fixed  or  general- 
purpose).  The  fixed  console  will  be  used  by  positions  which  re- 
quire continuous  or  near-continuous  manning.  The  general-purpose 
console  will  provide  a multifunction  operating  position. 

2.1.2  SMCC  Operating  Positions 

2. 1.2.1  STS  Mission  Director  (STSMD) . The  STSMD  will  be  responsi- 
ble for  the  overall  control  and  direction  of  all  STS  flights  sup- 
ported from  the  SMCC.  He  will  receive  periodic  status  reports  from 
SMCC  flight  director(s)  and  make  mission  management  decisions  based 
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MISSION 

DIRECTOR 
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TABLE  2-1 


SMCC  SUPPORT  MANNING  BY  POSITION 


POSITION 

NOMINAL 

CONTINGENCY 

TYPE 

CONSOLE 

STS  MISSION  DIRECTOR 

X 

X 

FIXED 

FLIGHT  DIRECTOR  (FD) 

X 

X 

FIXED 

TEST  CONTROLLER 

X 

X 

FIXED 

COMMAND  CONTROLLER  (ORBITER) 

X 

FIXED 

VEHICLE  ANALYST  (ORBITER) 

X 

X 

FIXED 

ELEC/EN V 

x ; 

GP 

COMM/INST 

x ; 

GP 

COMPUTER 

x 

GP 

G&N/CONTROL 

X 

GP 

FLIGHT  PLANS/TIMELINE 

X 

GP 

OPERATIONS  AND  PROCEDURES 

X 

GP 

FLIGHT  ANALYST  (ORB  & IUS) 

X 

X 

FIXED 

TABLE  2-2 

IUS  MANNING  BY  POSITION 


POSITION 

PRE-DEP 

PERIODS 

FR1 

FLI 

PER] 

:e- 

GHT 

ODS 

TYPE 

CONSOLE 

-i 

< 

HH 

X 

o 

>* 

o 

UJ 

CO 

z 

h 

o 

<_) 

< 

z 

o 

z 

(9 

HH 

X 

>- 
ee.  h- 
0*1 
> 
h-  H-t 
Z I- 

o <_> 
o< 

VEHICLE  ANALYST  (IUS) 

X 

X 

X 

X 

FIXED 

G&N/CONTROL 

X 

GP 

COMM/INST 

X 

GP 

COMMAND  CONTROLLER  (IUS) 

X 

X 

FIXED 

2-4 


on  overall  mission  and  flight  crew  safety  considerations.  Primary 
responsibilities  of  the  STSMD  are  to: 

• Provide  overall  control  and  direction  of  all  STS  flights 

• Disseminate  directives  of  the  STS  program  office  to  the 
flight  director(s) 

• Initiate  mission  operational  redirection  based  on  mission 
guidelines  and  objectives 

• Initiate  flight  termination  (if  required) , lengthen  or 
shorten  a mission,  or  redirect  Orbiter  landing  to  an  alter- 
nate landing  site 

• Ensure  that  all  support  activities  are  being  accomplished  in 
a manner  that  will  satisfy  flight  objectives 

• Approve  flight  plan  changes  during  inflight  operations 

• Approve  changes  in  mission  guidelines,  mission  rules,  pro- 
cedures, and  support  requirements 

• Evaluate  degree  of  contingencies  based  on  recommendations 
from  supporting  positions  (flight  director)  and  request  ad- 
ditional SCF  and/or  NASA  resources. 

Information  requirements  for  the  STSMD  are: 

• Mission  timeline/schedule  and  present  activity  point  along 
the  timeline 

• Groundtrack  and  present  Orbiter  location 

• Next  station  contact  (time  and  ID) 

• Flight  plan 

• Status  (GO/NO-GO)  of  flight  and  ground  systems 

• Time,  i.e.,  Greenwich  mean  time  (GMT),  ground  elapsed  time 
(GET),  and  mission  elapsed  time  (MET) 
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• Next  use  of  Orbiter  (time,  priority,  and  location) 

e Alternate  landing  site  status  (e.g.,  weather,  landing  aids) 
e Ferry  aircraft  availability 

• New  timeline  information 

• Payload  status  (GO/NO-GO) 

e Relative  position  (Orbiter,  satellite,  upper  stage  and  de- 
ployment/retrieval points) 

• IUS  groundtrack/present  position 

• Event  sequences 

e Contingency  alarm  (NO-GO  status  of  Orbiter  ground  systems) 

a Nature  of  failure,  e.g.,  Guidance  and  Navigatir  (G$N) 

System  and  trajectory  out-of-limits. 

2.1.2. 2 Flight  Director  (FD).  The  FD  will  be  responsible  to  the 
STSMD  for  mission  support  of  a specific  Shuttle  flight.  During 
nominal  mission  periods  the  FD  will  perform  those  normal  activities 
associated  with  the  overall  coordination  and  supervision  of  mis- 
sion operations.  During  contingency  situations  he  will  be  assisted 
by  the  Flight  Plans/Timeline  (paragraph  2. 1.2. 2, A)  and  Operations 
and  Procedures  (paragraph  2.1.2.2,B).  FD  responsibilities  are: 

• Manage  SCF  operational  activities  in  real-time  to  ensure 
satisfactory  accomplishment  of  mission  objectives 

• Direct/redirect  STC  elements  as  required  to  accomplish  mis- 
sion objectives 

• Determine  and  direct  the  accomplishment  of  alternate  command 
plans  in  real-time 

• Implement  alternate  procedures  to  ensure  program  objectives 
are  satisfied 

• Primary  voice  interface  with  Orbiter 
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• Provide  overall  coordination  of  SCF  resources  with  responsi- 
ble agencies  when  conflicts  arise 

• Coordinate  with  payload  Mission  Control  Center  (MCC)  user 
and  STS  disciplines  in  support  of  mission  mangement  decisions 

• Maintain  status  of  landing  site 

• Maintain  awareness  of  mission  status  (GO/NO-GO  for  mission 
events  and  activities) 

• Assist  STSMD  in  determination  of  contingency  manning 

• Evaluate  degree  of  contingency  and  determine  need  for  in- 
creased manning  when  within  operational  guidelines  of  the 
STSMD 

• Direct  and  supervise  the  implementation  of  security  plans 
and  procedures 

• Coordinate  the  release  of  all  operational  communications  pe- 
culiar to  mission  support  to  NASA  or  other  agencies. 

Information  requirements  for  the  FD  are  the  same  as  the  STSMD  plus 
the  following: 

• An  additional  level  of  payload  status  data 

• Flight  plan  changes  and  projections  of  impact  to  user 

• Flight  plan  variations 

• Mission  activity  variations 

• RTS  support  schedule/capabilities 

• Landing  site  status* 

A.  Flight  Plans/Timeline.  The  Flight  Planner  (FP)  will  be 
responsible  to  the  FD  for  monitoring  and  updating  the  mis- 
sion flight  plan  during  contingency  support  periods.  Pri- 
mary responsibilities  of  the  FP  are  to: 

• Perform  planning,  coordination,  and  implementation  of 
all  mission  activity  changes  with  STS  disciplines 
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• Provide  detailed  flight  plan  development  and  crew  pro- 
cedures during  contingency  mission  phases  to  the  FD 

• Provide  summary  planning  information  for  optimization  of 
the  mission  objectives 

• Prepare  detailed  crew  procedures  and  timeline  schedules 
in  line  with  mission  objectives  and  vehicle/crew  con- 
straints. 

Flight  Plans/Timeline  information  requirements  are: 

e Flight  plan-baseline/updated 

• Timeline-baseline/updated 

• Crew  procedures 

• Crew  activities  schedule/crew  equipment 

• Time 

• Mission  rules/objectives 

• Event  sequence 

• Mission  resources  (Orbiter  and  crew) 

• Groundtrack. 

B.  Operations  and  Procedures  (0$P) . The  0§P  position  will 

provide  support  to  the  FD  during  contingency  periods.  Re- 
sponsibilities of  the  0§P  position  are  to: 

e Coordinate  implementation  of  the  contingency  mission 
control  procedures 

• Coordinate  data  management  timelines 

• Coordinate  utilization  of  ground  processing  and  data 
distribution  with  other  team  members  and  remote  control 
areas  (user  MCC) 

• Coordinate  recovery  of  mission  data  from  remote  sites 
and  data  storage. 
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C§P  information  requirements  are: 

• Timeline/schedules 

• Flight  plan 

• Next  station  contact 

• Acquisition  of  signal/loss  of  signal  times 

• Station  configuration  and  SMCC  system  status 

• Mission  rules/mission  objectives 

• Groundtrack 

e Data  source/format 
e Time  and  event  sequences. 

2. 1.2.3  Test  Controller  (TC) . The  TC  will  be  responsible  to  the 
FD  for  the  overall  command  and  control  coordination  between  the 
SMCC  and  the  Remote  Tracking  Station  (RTS).  Other  TC  responsi- 
bilities are  to: 

• Supervise  the  activities  of  allocated  AFSCF  resources 

• Coordinate  with  network  scheduling  for  normal  and  contin- 
gency scheduling 

• Control  voice  and  data  interfaces  with  RTS's 

• Provide  prime  SMCC  secure  voice  communications  interface 
between  the  Orbiter  and  FD 

• Monitor  transmission  of  all  program  data  between  the  Orbiter 
vehicle  and  the  STC 

• Initiate,  control,  and  conduct  all  prepass,  pass,  and  post- 
pass  briefings  with  support  personnel 

• Provide  the  backup  to  command  and  configuration  tasks  by  the 
command  controller 

• Coordinate  contingency  network  support  with  NASA. 
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Information  requirements  for  the  TC  include: 

• Timeline/schedule 

• National  Oceanic  and  Atmospheric  Administration  (NOAA) 
weather  inputs 

• Flight  plan 

• Next  station  contact 

• Groundtrack 

• SMCC  System(s)  status  - GO/NO-GO 

• Landing  site  status 

• RTS  status/configuration 

• RTS  support  schedule/capabilities 

• Space  Tracking  and  Data  Network  (STDN)  support  status/ 
capabilities 

• Communications  plan 

• STS  tracking/next  station  contact 

• Incoming  data  status,  i.e.,  data  sync  and  data  source 
(vehicle) 

• Time 

• Command  status/review 

• Command  flow 

• Active  uplink  site/alternate  uplink  site 

• Command  data  location 

• Acquisition  of  signal/loss  of  signal  times 

• Event  sequence. 
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2. 1.2. 4 Command  Controller  (Orbiter).  The  Command  Controller  (CC) 
will  be  responsible  to  the  TC  for  the  overall  status  of  the  SCF 
command  capability  tor  the  Orbiter.  This  position  will  be  manned 
during  contingencies  and  during  periods  of  activity  which  require 
increased  ground  support.  Primary  responsibilities  of  the  CC  in- 
clude the  following  tasks: 

• Monitor  and  control  command  generation,  review,  and  transfer 
of  real-time  commands  and  command  loads 

• Monitor  and  control  SCF  network  command  capability 

• Monitor  command  flow  through  SCF  network 

• Prepare  and  recommend  changes  to  the  pass  plan 

• Complete  the  command  prepass  checks 

• Obtain  command  summaries. 

CC  information  requirements  are: 

• Command  status/review 

• Command  flow 

• Active  uplink  site/alternate  uplink  site 

• Command  data  location  - site  loads  in  core 

• Flight  plan 

• Timeline/schedule 

• Time 

• Command  verification/reject  status 

• Acquisition  of  signal/loss  of  signal  times 

• Groundtrack 

• Next  station  contact 

• KTS  status/configuration 

• Event  sequence. 
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2. 1.2. 5 Flight  Analyst  (FA).  The  FA  position  provides  support  to 
both  the  IUS  and  Orbiter  during  nominal  and  contingency  support 
periods.  Functions  of  the  FA  in  support  of  IUS  operations  are 
listed  in  paragraph  2. 1.3. 3. 

The  FA  will  be  responsible  for  the  trajectory  analysis  activities 
during  all  phases  of  the  mission  including  all  ascent  trajectory 
monitoring,  Terminal  Area  Energy  Management  (TAEM)  , and  approach/ 
landing  position  data.  The  FA  position  will  monitor  and  evaluate 
Orbiter  and  IUS  trajectory  and  provide  trajectory  status  data  to 
the  FD,  other  SMCC  positions,  and  user  MCC's.  This  status  data  will 
permit  evaluation  of  trajectory  acceptability  and/or  permit  manage- 
ment decisions  on  maneuvers  required  to  maintain  a nominal  mission 
or  replan  for  an  alternate  mission. 

Primary  functions  of  the  FA  are  to: 

• Transmit  tracking  and  commanding  prepass  tapes  and  command 
messages  (IUS/Tug) 

• Transmit  RTS  tracking  data  for  Orbiter  acquisition  and  pass 
support 

• Monitor  and  assist  reentry/landing  planning  operations 

• Monitor  and  control  the  offline  flight  support  computer 
scheduling  and  utilization 

• Maintain  mission  trajectory  profile 

• Provide  GO/NO-GO  status  of  Orbiter  trajectory  to  management 

• Analyze  trajectory  impacts  on  flight  plan 

• Participate  in  mission  design  replanning 

• Analyze  trajectory  impacts  on  Orbiter  systems 

• Update  Orbiter  ephemeris/state  vector  (current  and  desired) 
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• Predict  day/night  schedules 

• Provide  inputs  to  rendezvous  planning 

• Monitor  and  evaluate  Orbiter  maneuvers. 

FA  information  requirements  are: 

• NOAA/weather  inputs 

• Orbital  ephemeris/s tate  vector  (current  and  desired) 

• Flight  plan 

• Timeline/schedule 

• Target  vehicle  state  vector 

• Consumables  usage  tables/Propuls ion  System's  status 

• Station  contact  schedule 

• STS  tracking/next  station  contact 

• Sun  rise/set  schedules 

• Acquisition  of  signal/loss  of  signal  times 

• Command  verify/reject 

• Next  station  contact 

• Time  and  event  sequence 
e Groundtrack 

• Maneuver  tables 

• RTS  status/configuration. 

2. 1.2.6  Vehicle  Analyst  - Orbiter  (VAO).  The  VAO  will  maintain 
top-level  status  of  Orbiter  systems  status  and  Orbiter  configura- 
tion during  nominal  mission  activities.  Periodic  progress  reports 
and  mission  essential  consumables  will  be  maintained  by  the  VAO. 
Significant  changes  in  system  status  which  require  real-time  ac- 
tion will  be  reported  to  the  FD.  The  VAO  will  support  prepass  ac- 
tivities and  analyze  data  resulting  from  pass  or  postpass  activi- 
ties . 
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During  contingencies  the  VAO  will  be  assisted  by  subsystem  per- 
sonnel. These  positions  will  be  manned  as  required  and  will  pro- 
vide the  VAO  with  periodic  mission  progress  reports  and  mission- 
essential  consumables  status  reports  related  to:  (1)  Electrical/ 

Environmental;  (2)  Communications/Instrumentation;  (3)  G§N/Control , 
and  (4)  Computer  Systems.  This  data  will  be  used  to  advise  the 
FD  of  mission  progress  and  as  tools  in  replanning  if  required. 

Primary  functions  of  the  VAO  are  to: 

• Maintain  top-level  status  of  Orbiter  configuration,  i.e., 
vehicle  problem  analyses  and  monitor  pay load/Orbiter  inter- 
facing subsystem  status 

• Analyze  flight  plan  changes  impact  on  Orbiter  systems 

• Assist  mission  management  in  replanning  as  required. 

VAO  information  requirements  are: 

• Timeline/schedules 

• Flight  plan 

• Orbiter  system(s)  status  - GO/NO-GO  and  system*  data 

• Time  and  event  sequences 

• Consumables  tables  and  maneuver  tables 

• Mission  rules/mission  objectives 

• Command  verify/reject 

• Resources  (Orbiter,  payload,  SCF/STDN) 

• Orbiter/target  state  vector. 

A.  Electrical/Environmental.  The  electrical  and  environmental 
position  is  responsible  to  the  VAO,  for  analysis  of  the  Or- 
biter Electrical  Power  System  (EPS)  and  the  Environment  Con- 
trol System  (ECS) . The  position  will  report  GO/NO-GO  status 
based  on  evaluation  of  systems  performance  and  trend  data. 
Electrical/Environmental  information  requirements  are: 

• Timeline/schedule 
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• Flight  plan 

• System  telemetry  data  (batteries,  fuel  cells,  power 
consumption,  power  distribution  and  life  support 
consumables/systems  status) 

• Time  and  event  sequence. 

B.  Communications/Instrumentation.  The  Communications  and  In- 
strumentation position  is  responsible  to  the  VAO  for  analy- 
sis of  the  Orbiter  communications  and  instrumentation  sys- 
tems. This  position  will  report  GO/NO-GO  status  based  on 
evaluation  of  systems  performance  and  trend  data. 

Communications/instrumentation  information  requirements 
are : 

• Timeline/schedule 

• Flight  plan 

• System(s)  telemetry  data  (communication:  and  instrumen- 
tation) 

• Time  and  event  sequence. 

C.  G5N/Control.  The  G§N/Control  position  is  responsible  to 
the  VAO  for  analysis  of  the  Orbiter  G§N  and  Control  Systems. 
This  position  will  report  GO/NO-GO  status  based  on  evalua- 
tion of  systems  performance  and  trend  data.  Functions  of 
this  position  are  to: 

• Monitor  and  evaluate  G§N  systems  performance 

• Evaluate  onboard  computer  information  - flight  program 

• Monitor  and  evaluate  Orbiter  Propulsion  System's  status 
and  trends 

• Monitor  and  evaluate  Attitude  Control  System's  status 
and  trends. 
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G§N/Control  information  requirements  are: 

• Timeline/schedule 

• Flight  plan 

• Groundtrack/next  station  contact 

• G§N  System  telemetry  data 

• Maneuver  tables 

• STS  tracking/next  station  contact 

• Consumables 

• Time  and  event  sequence 

• Flight  program 

• Orbiter  state  vector 

• Target  state  vector 

• Landing  coordinates. 

D.  Computer.  The  computer  position  is  responsible  to  the  VAO 
for  analysis  of  the  Orbiter  Onboard  Computer  System's  per- 
formance and  status.  Primary  functions  of  this  position 
are  to: 

• Monitor  and  evaluate  onboard  computer  performance,  trends, 
and  configuration 

• Provide  support  for  onboard  software  functions. 

Computer  position  information  requirements  are: 

• Timeline/schedule 

• Flight  plan 
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• Orbiter  onboard  computer  telemetry  data  such  as  process 
ing  allocation,  software  monitor,  and  processor  manage- 
ment 

• Time  and  event  sequence 

• Flight  program. 

2.1.3  Interim  Upper  Stage  (IUS)  Operating  Positions 

2.1.3. 1 Command  Controller  (IUS/Tug).  The  CCIUS  will  be  re- 
sponsible to  the  TC  for  the  SCF  command  capability  for  the  IUS. 

He  will  provide  the  FD  with  IUS  status  data  and  evaluate  new  mis- 
sion requirements  impacts.  In  addition,  he  will  make  recommenda- 
tions for,  and  evaluate,  flight  plan  changes. 

Primary  functions  of  the  CCIUS  are  to: 


• Direct  command  operations  at  the  RTS 

• Generate  IUS  commands  for  transmission  to  RTS  and  uplink  to 
IUS 

• Coordinate  IUS/satelli te  operations  for  satellite  deployment 
and  handover  involving  the  IUS 

• Maintain  overall  status  of  IUS  and  flight  plan  variations 

• Provide  assistance  to  the  FD  in  mission  replanning  for  areas 
pertinent  to  IUS  operation 

• Verify  satellite  data  integrity  during  IUS/satellite  opera- 
ti  ons 

• Advise  the  STSMD  and  the  FD  of  contingency  situation  and  de- 
termine or  assist  in  the  determination  of  corrective  action. 

Information  requirements  for  the  CCIUS  are: 

• Mission  timeline  and  present  activity  point  (Orbiter  and 
IUS) 
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• Groundtrack  and  present  location  (Orbiter  and  IUS) 

• Next  station  contact  (IUS) 

• Flight  plan 

• Status  (GO/NO-GO)  of  flight  and  ground  systems 

• Time  (GMT,  GET,  MET) 

• New  timeline  information 

• Payload  status  (GO/NO-GO) 

• Relative  position  (Orbiter,  satellite,  IUS  and  deployment/ 
retrieval  points) 

• Event  sequences 

• Mission  rules,  guidelines,  and  procedures 

• Satellite/IUS  interface  status  checks 

• Mission  planning  data  (e.g.,  consumables,  consumables  trends, 
maneuver  tables,  and  rendezvous  tables) 

• System  status  displays 

• Site  acquisition  tables 

• Network  status 

• Station  configuration 

• Command  status/review  (IUS) 

• Command  flow 

• Active  uplink  site/alternate  uplink  site. 
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2. 1.3. 2 Vehicle  Analyst  - IUS  (VAIUS).  The  VAIUS  position  will 
be  responsible  for  maintaining  system  status  of  the  IUS  during 
free-flight  or  providing  assistance  in  contingency  situations  when 
the  IUS  is  stowed  in  the  Orbiter  payload  bay.  Some  contingency 
situations  may  require  more  detailed  analysis  of  IUS  subsystems. 
During  these  periods  the  VAIUS  will  be  assisted  by  the  IUS  G§N/ 
Control  and  Communications/Instrumentation  positions. 

Primary  responsibilities  of  the  VAIUS  are  to: 

• Evaluate  proposed  flight  plan  changes  for  impact  to  IUS  sys- 
tems 

• Monitor  and  maintain  status  of  IUS  systems 

• Format  and  transmit  real-time  commands  and  command  loads  to 
RTS 

• Assist  FD  in  mission  planning  activities 

• Perform  IUS  malfunction  analysis  and  recommend  corrective 
action. 


Information  requirements  for  the  VAIUS  are: 

• Mission  timeline  and  present  activity  point  (Orbiter  and 
IUS) 

• Groundtrack  and  present  location  (Orbiter  and  IUS) 

• Flight  plan 

• IUS  systems  GO/NO-GO  status  (e.g.,  sensor,  communications, 
propulsion,  instrumentation) 

t Time  (GMT,  GET,  MET) 

0 Additional  timeline  information  and  timeline  changes 
0 Payload  status  (GO/NO-GO) 
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• Event  sequences 


• Mission  rules,  guidelines  and  procedures  as  applied  to  IUS 
systems 

• Satellite/IUS  interface  status  checks 

• System  tabs  (tabular  listing  of  systems  data). 

A.  GfiN  Control.  The  G5N/Control  monitor  is  responsible  to  the 
VAIUS  for  the  analysis  of  IUS  G§N,  propulsion,  attitude 
control,  vehicle  sequencing  and  computer.  GO/NO-GO  status 
will  be  reported  based  on  evaluation  of  system  status  and 
trend  data.  He  will  perform  malfunction  analysis  on  those 
systems  for  which  he  is  responsible  and  will  provide  assist- 
ance to  the  VAIUS  in  the  determination  of  contingency  sup- 
port. The  G5N/Control  position  will  be  manned  during  con- 
tingency or  high  activity  periods  during  IUS  free-flight. 

Information  requirements  for  the  G&N/Control  are: 

• Mission  timeline  and  present  activity  point  (Orbiter  and 
IUS) 

• Groundtrack  and  present  location  (Orbiter  and  IUS) 

• Flight  plan 

• Time  (GMT,  GET,  MET) 

• Additional  timeline  information  and  timeline  changes 

• IUS/satellite  interface  status 

• Mission  rules,  guidelines,  and  procedures 

• 


Event  sequences 


• Systems  tabs  and  trends  to  include  inertial  measurement 
unit,  attitude  measuring  sensors,  attitude  control,  com- 
puter hardware  and  software,  accelerometers,  star  trackers/ 
horizon  sensors,  sequential  system,  main  engine,  propul- 
sion tank  management,  consumables  utilization,  mass 
management,  and  structures  and  thermal  control 

• Maneuver  tables 

• Rendezvous  tables. 

B.  Communications /Instrument at  ion.  The  Communications/ 

Instrumentation  monitor  is  responsible  to  the  VAIUS  for  the 
analysis  of  the  IUS  communications,  instrumentation,  and 
EPS.  GO/NO-GO  status  will  be  reported  based  on  evaluation 
of  system  status  and  trend  data.  He  will  perform  malfunc- 
tion analysis  on  those  systems  for  which  he  is  responsible 
and  will  provide  assistance  to  the  VAIUS  in  the  determina- 
tion of  contingency  support.  This  position  will  be  manned 
during  contingency  or  high  activity  periods  during  IUS  free- 
flight. 

Information  requirements  for  the  Communications/ 
Instrumentation  position  are: 

• Mission  timeline  and  present  activity  point  (Orbiter  and 
IUS) 

• Groundtrack  and  present  location  (Orbiter  and  IUS) 

• Flight  plan 

• Time  (GMT,  GET,  MET) 

• Additional  timeline  information  and  timeline  changes 

• IUS/satellite  interface  status 

• Mission  rules,  guidelines,  and  procedures 

• Event  sequences 
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• System  tabs  and  trends  to  include  power  distribution, 
power  consumption,  batteries,  heaters,  radiators,  com- 
munications systems  (e.g.,  S-band,  TV),  signal  condi- 
tioners, command  receiver,  sensors,  and  multiplexers. 

2. 1.3. 3 Flight  Analyst  - IUS  (FAIUS) . The  FAIUS  position  will  be 
combined  with  the  FAO  position.  For  the  IUS  the  FA  will  provide 
support  in  orbit  determination,  ephemeris  generation,  and  maneuver 
planning.  In  performance  of  this  task  he  will  compare  actual  tra- 
jectory data  with  desired  trajectory  and  participate  in  malfunction 
analysis  in  contingency  situations.  Primary  functions  of  the  FAIUS 
are  to: 

• Assist  in  mission  management  decision  making  which  requires 
IUS  trajectory  data 

• Notify  satellite  user  personnel  of  changes  in  IUS  orbital 
state 

• Perform  IUS  maneuver  and  rendezvous  planning  activities 

• Perform  trajectory  analysis  and  make  recommendations  for 
corrections  to  non-nominal  trajectory  profile 

• Prepare  and  initiate  commands  and  command  loads  for  IUS  Or- 
bital state  corrections. 

Information  requirements  for  the  FAIUS  are: 

t Mission  timeline  and  present  activity  point  (Orbiter  and 
IUS) 

• Groundtrack  and  present  location  (Orbiter  and  IUS) 

• Flight  plan 

• IUS  systems  GO/NO-GO  status 

• Time  (GMT,  GET,  MET) 

• Additional  timeline  information  and  timeline  changes 
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• Payload  status  (GO/NO-GO) 

• Event  sequences 

• Mission  rules,  guidelines,  and  procedures 

• Maneuver  planning  tables 

• Rendezvous  tables 

• IUS  attitudes 

• IUS  mass  properties 

• Trajectory  profile  (Orbiter  ij  IUS) 

• Ephemeris  tables  (Orbiter  § IUS). 

2.1.4  Manning.  The  SMCC  operating  positions  will  provide  support 
to  both  the  Orbiter  and  the  IUS.  For  the  Orbiter  this  support  is 
divided  into  nominal  and  contingency.  For  the  IUS  this  support  is 
divided  into  stowed  operations  and  free-flight  operations;  these 
periods  are  then  further  subdivided  into  nominal  and  contingency. 

2. 1.4.1  Orbiter  Manning.  During  nominal  support  periods  the  SMCC 
operating  positions  to  be  manned  are:  STSMD,  FD,  TC,  VAO,  and  FA- 

Orbiter.  It  is  anticipated  that  the  STSMD  will  not  be  on  duty  at 
all  times  and  in  his  absence  the  FD  will  assume  his  responsibili- 
ties. The  other  positions  would  be  manned  at  all  times. 

In  Task  III  it  was  baselined  that  the  amount  of  contingency  support 
will  be  dependent  on  the  mission  situation.  In  determining  the 
manning  for  contingencies,  it  is  assumed  that  all  contingencies 
will  require  higher  activity  in  the  areas  of  Flight  Plans/Timeline 
and  Operations  and  Procedures.  Command  and  control  requirements 
are  also  anticipated  to  increase  during  contingency  situations. 
Thus,  these  positions  (Flight  Plans/Timeline,  Operations  and  Pro- 
cedures, and  Command  and  Control)  will  be  manned  for  the  majority 
of  contingency  situations.  Other  positions  are  for  systems  support 
and  will  be  manned  on  an  as  required  basis.  These  positions  are 
Electrical/Environmental,  Communications/Instrumentation,  G§N/ 
Control  and  Computer. 
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2. 1.4.2  IUS  Manning.  During  nominal  support  periods  when  the  IUS 
is  stowed  in  the  payload  bay  only  the  VAIUS  position  will  be  manned. 
For  nominal  periods  when  the  IUS  is  in  free-flight  additional  sup- 
port will  be  provided  by  the  CCIUS  position. 

For  contingency  support  periods  when  the  IUS  is  stowed  in  the  pay- 
load  bay  the  only  IUS  support  position  to  be  manned  is  the  VAIUS. 
During  contingency  or  high-activity  periods  (e.g.,  payload  deploy- 
ment, midcourse  correction  planning,  and  execution)  all  IUS  posi- 
tions will  be  manned  to  include:  VAIUS,  G§N/Control,  Communications/ 

Instrumentation,  CCIUS  and  FAIUS. 

2.1.5  Console  Utilization.  Two  types  of  consoles  will  be  used  by 

SMCC  personnel.  These  are:  fixed  and  general-purpose. 

Fixed  consoles  are  provided  for  the  STSMD,  FD,  TC,  CC  (Orbiter) , 

VAO , FA  (Orbiter),  FAIUS,  CCIUS  and  VAIUS. 

Fixed  consoles  will  be  configured  as  required  for  these  specific 
operating  positions.  Control  modules  used  for  command  uplink, 
command  enable/disable,  and  data  entry  will  be  provided  according 
to  individual  console  requirements.  Each  console  will  be  provided 
a cathode  ray  tube  (CRT)  display,  display  request  module,  and 
communications  circuits. 

General-purpose  consoles  will  be  configured  for  multifunction  usage. 
Generally,  these  consoles  will  provide  a CRT  display  device,  dis- 
play request  capability,  data  entry  device  and  communication  cir- 
cuits. General-purpose  consoles  will  provide  additional  support 
capability  for  contingency  situations.  Six  general-purpose  con- 
soles will  be  provided  to  be  used  by  the  Flight  Plans/Timeline, 
Operations  and  Procedures,  Electrical/Environmental,  Communications/ 
Instrumentation,  GfiN/Control  and  Computer  operating  positions  on 
an  as-required  basis.  Two  additional  general-purpose  consoles  will 
be  provided  for  contingency  support  of  the  IUS. 

2.1.6  Control  and  Voice  Communication  Requirements.  Table  2-3 
shows  the  control  and  voice  communication  requirements  by  position. 
Control  requirements  are  divided  into  display  request,  command  up- 
link, command  enable/disable  and  general  data  entries.  Communica- 
tion requirements  are  inter-  and  intra-center  and  inter-agency 
voice  communication  links. 
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TABLE  2-3 

VOICE  COMMUNICATIONS  AND  CONTROL  REQUIREMENTS 
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2.1.7  Information  Requirements.  Each  of  the  preceding  paragraphs 
describe  the  information  requirements  by  position  in  support  of  ; ■ 

the  Orbiter  and  IUS.  Tables  2-4  and  2-5  present  a summary  of  these 
information  requirements  by  position. 
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TABLE  2-4 

INFORMATION  REQUIREMENTS  BY  POSITION  (ORBITER) 


MISSION  TIHELIHE/SCHEOOLE 

GROUND  TRACK 

NEXT  STATION  CONTACT 

FLIGHT  PLAN 

GO/NO  GO  SYSTEM  STATUS 


ORBITER  NEXT  USE 

ALT  LANl.  SITE  STATUS 

FERRY  AIRCRAFT  AVAILABILITY 

NEW  TIMELINE  INFO 

CO/NO  GO  PAYLOAD 

RELATIVE  POSITION 

IUS  GROUND  TRACK 

EVENT  SEQUENCE 

CONTINGENCY  ALARM 

NATURE  OF  FAILURE 

MODE  DETAILED  PAYLOAD  STATUS 

FLIGHT  PLAN  ChANGES 

MISSION  ACTIVITY  CHANCES 

ACQUISITION/LOSS  OF  SIGNAL  TIMES 

STATION  CONFIGURATION 

MISSION  RULES/GUIDELINES/PROCEDURES 

DATA  SOURCE/FORMAT 

NOAA/WEATHER 

GO/NO  GO  SMCC  SYSTEMS 

GC/NO  GO  NETWORK  STATUS 

LANDING  SITE  STATUS 

CREW  PROCEDURES 

III  ISION  RESOURCES 

CONSUMABLES  TABLES 

SYSTEN-S  DATA  (ORBITER) 

COWAND  VERIFY/REJECT 

MANEUVER  TABLES 

CREW  ACTIVITIES 

FLIGHT  PROGRAM 

ORBITER  STATE  VECTOR 

TARGET  STATF  VECTOR 

SUN  RISE/SET  SCHEOULE 

RTS  STATUS/CONFIGURATION 

RTS  SUPPORT  SCHEOULE/CAPABI CITIES 

STDN  SUPPORT  STATUS/CAPABILITIES 

COWUN1CATIONS  PLAN 

STS  TRACKING/NEXT  STATION  CONTACT 

INCOMING  DATA  STATUS 

COMMAND  STATUS/REVIEW 

COMMAND  FLOW 

ACTIVE  UPLINK  SITE/ALTERNATE  UPLINK  SITE 
COWAND  DATA  LOCATION 
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FA  (ORBITER) 


TABLE  2-5 

INFORMATION  REQUIREMENTS  BY  POSITION  (IUS) 


INFORMATION 


MISSION  TIMELINE/SCHEDULE 
GROUND  TRACK 

NEXT  STATION  CONTACT  (IUS) 

FLIGHT  PLAN 

GO/NO  GO  SYSTEM  STATUS  (IUS) 

TIME 

NEW  TIMELINE  INFO 
GO/NO  GO  PAYLOAD  STATUS 
RELATIVE  POSITION 
EVENT  SEQUENCE 

MISSION  RULES/GUi DELINES/PROCEDURES 
SAT/  IUS  I/F  STATUS  CHECKS 
MISSION  PLANNING  DATA 
SYSTEM  STATUS  DISPLAYS 
SITE  ACQUISITION  TABLES 
NETWORK  STATUS 

DETAILED  SYSTEMS  DATA  (STATUS  & TRENDS) 

MANEUVER  TABLES 

RENDEZVOUS  TABLES 

IUS  ATTITUDES 

IUS  MASS  PROPERTIES 

TRAJECTORY  PROFILE 

ORBITER  STATE  VECTOR 

IUS  STATE  VECTOR 

COMMAND  CONFIGURATION 

COMMAND  STATUS/REVIEW  (IUS) 

COMMAND  FLOW 

ACTIVE  UPLINK  SITE/ALTERNATE  UPLINK  SITE 
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FLIGHT  ANALYST 


2.2 


OPERATIONAL  CONCEPT 


The  SMCC  is  that  element  from  which  total  mission  management  and 
support  of  the  STS  flight  elements  and  operations  are  conducted. 
During  preflight  the  SMCC  will  participate  in  simulations,  re- 
hearsals, and  systems  readiness  exercises.  During  flight  phases, 
the  SMCC  maintains  sufficient  cognizance  of  Orbiter/IUS  trajec- 
tories, events,  systems  status,  and  crew  status  to  exercise  overall 
management  of  the  mission  including  offline  mission  replanning. 
Communications  are  maintained  with  other  CCDS  elements  as  required. 

This  paragraph  discusses  SMCC  operations  concepts  as  related  to: 

• Command  generation  and  initiation 

• RTS  coordination 

• Data  entry 

• Display  requests. 

2.2.1  Command  Generation  and  Initiation.  Commands  will  be  gener- 
ated by  SMCC  software  upon  request  by  SMCC  operating  positions. 
Types  of  commands  to  be  generated  include  real-time  commands  and 
command  loads.  Real-time  commands  apply  to  discrete  actions  such 
as  "recorder  dump"  or  "antenna  switching"  and  would  normally  be 
stored  premission.  Command  loads  apply  to  onboard  system  updates 
such  as  "state  vector"  update  and  "time"  update  and  require  the 
generation  of  parameters  relative  to  the  type  of  update.  Commands 
will  be  generated  either  by  specific  requests  from  an  operating 
position  or  by  a series  of  interactive  actions  between  the  oper- 
ating position  and  the  command  generation  software.  SMCC  operating 
positions  which  will  be  provided  command  generation  capability  will 
be  the  FA,  VAO,  VAIUS,  CC  (Orbiter) , CCIUS,  and  TC. 

Command  initiation  will  provide  these  same  operating  positions  with 
the  capability  to  initiate  a "command  uplink"  from  the  SMCC  to  the 
Orbiter  via  the  RTS.  The  initiation  of  a command  uplink  will  occur 
after  a command  is  formatted  for  output  to  the  Orbiter  and  will  re- 
quire the  console  operator  to  perform  a specific  action  such  as 
pushbutton  indicator  (PBI)  depression. 

Command  enable/disable  capability  is  provided  to  the  TC,  CC  (Orbi- 
ter), and  CCIUS.  Command  enable/disable  allows  a console  position 
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to  he  selected  for  command  initiation.  During  nominal  support 
periods,  command  enable/disable  capability  will  be  performed  by 
the  TC.  During  contingency  support  periods  command  enable/disable 
will  be  performed  by  the  CC.  For  IUS  commands  during  IUS  free- 
flight  periods  command  enable/disable  capability  will  be  performed 
by  the  CCIUS.  The  implementation  of  the  command  enable/disable 
capability  must  also  consider  requirements  by  the  user  to  format 
and  send  commands  via  the  Orbiter  when  the  satellite  is  under  con- 
trol of  the  Orbiter. 

2.2.2  RTS  Coordination.  Voice  contact  will  be  provided  between 
the  SMCO  and  the  RTS  prior  to  pass  support,  during  the  pass,  and 
postpass.  The  FA  will  perform  this  function  during  nominal  support 
periods.  Contact  prior  to  the  pass  will  be  for  the  transfer  of 
acquisition  and  any  changes  to  the  pass  support  plan,  and  to  verify 
the  RTS  is  configured  for  Orbiter  support.  During  the  pass,  coor- 
dination will  be  for  the  verification  of  data  quality  and  verifi- 
cation that  the  pass  plan  is  being  implemented.  Postpass  contacts 
will  be  for  problem  reporting  and  to  make  changes  in  pass  support 
schedules.  During  contingency  situations,  the  CC  position  will  be 
manned  and  this  position  will  coordinate  RTS  support  activities. 

2.2.3  Data  Entry.  Data  entry  devices  will  be  provided  on  the 
general-purpose,  ~VAO,  VAIUS,  and  FA  consoles.  Entry  devices  may 
include  alphanumeric  keyboards,  fixed  function  keyboards,  and  pro- 
grammable function  keyboards.  These  devices  will  provide  operating 
positions  with  the  capability  to  request  additional  information, 
control  computer  programs,  perform  interactive  data  analysis,  and 
enter  general  information. 

2.2.4  Display  Requests . Each  console  will  be  provided  a display 
request  capability.  TEis  capability  may  be  provided  through  the 
implementation  of  a display  request  module,  programmable  function 
module,  or  alphanumeric  keyboard.  The  display  request  module 
would  provide  only  a display  request  capability.  The  programmable 
function  module  would  provide  for  a display  request  as  well  as  for 
other  functions  such  as  program  control.  The  alphanumeric  key- 
board would  provide  for  data  entry  as  well  as  display  request 
capability . 

Displays  will  be  available  to  SMCC  operating  positions  dependent 
on  mission  phase,  mission  situation  (nominal  or  contingency)  and 
predefined  mission  requirements.  Displays  will  generally  be  on 
formats  specified  premission  with  updates  to  mission-specific  param- 
eters according  to  display  requirements. 
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DUAL  MISSION  SUPPORT 


2.  3 

Dual  mission  support  may  be  required  for  two  Orbiters  or  for  one 
Orbiter  and  one  Orbiter/IUS/satellite  combination  requiring  simul- 
taneous service.  In  developing  a dual  mission  operations  concept 
two  functional  configurations  were  assumed  as  candidates.  Config- 
uration one  (figure  2-2j  provides  the  minimum  dual  mission  support 
capability  required  by  the  DOD  guidelines  listed  below.  Configur- 
ation two  (figure  2-3)  provides  additional  capabilities  which  are 
considered  desirable  for  dual  mission  support. 

DOD  guidelines  provided  for  dual  mission  support  are  that: 

• Simultaneous  contingency  support  will  not  be  required 

• Single  station  RTS's  will  not  be  shared 

• SMCC/AFSCF  facilities  and  hardware  are  "identical"  for  pur- 
poses of  mission  support,  i.e.,  neither  Orbiter  has  unique 
support  requirements 

• It  is  operationally  unacceptable  to  "time-share"  a console/ 
position;  this  would  jeopardize  both  mission  success  and 
vehicle  safety 

• Payload  data  may  be  required  from  each  Orbiter  simultaneously; 
payload  is  used  here  in  the  broad  concept  to  include  upper 
stages 

• Except  for  voice,  only  one  data  stream  would  be  processed  at 
one  time 

• Handling  of  digital  voice  and  recording  of  data  will  be  pro- 
vided for  dual  missions. 

2.3.1  Configuration  1 for  Dual  Mission  Support.  Figure  2-2  pre- 
sents an  SMCC  functional  configuration  (configuration  1)  for  sup- 
port of  DOD  dual  missions.  Foi  convenience  in  defining  the  SMCC 
support  configuration,  missions  are  designated  as  missions  A and  B. 
In  this  configuration,  mission  A is  the  primary  mission  and  mission 
B is  the  secondary  mission.  As  applied  to  this  configuration, 
"primary"  refers  to  the  mission  for  which  applications  processing 
is  provided  as  a result  of  high  activity,  contingency  support,  or 
nominal  processing.  "Secondary"  pertains  to  the  mission  for  which 
voice  only  is  being  processed  and  the  telemetry  data  is  recorded. 

Inputs  to  the  SMCC  consist  of  Orbiter  and  payload  telemetry  and 
voice  for  both  missions.  For  this  configuration  the  capability 
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Figure  2-2  Dual  Mission  Support  Functional  Configurati 
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Figure  2-3  Alternate  Dual  Mission  Support  Functional  Configuration 


is  provided  for  receiving  and  processing  of  both  downlinks  simul- 
taneously. Processing  consists  of  receiving  A and  B mission  in- 
puts and  verifying  data  quality,  communications  processing,  data 
recording,  and  stripping  out  of  the  digital  voice  data.  Applica- 
tions processing  is  provided  for  the  prime  mission.  Both  a prime 
and  backup  applications  processor  are  provided  for  the  prime  mission. 
Backup  applications  processing  is  provided  only  during  contingency 
support  periods.  In  addition,  payload  data  from  both  the  prime  and 
secondary  mission  is  routed  to  the  payload  data  systems  for  pro- 
cessing and  distribution  to  the  user  MCC's.  Digital  voice  is  pro- 
cessed and  routed  to  the  appropriate  mission  control  areas.  The 
capability  is  provided  for  voice  transmission  to/from  the  separate 
control  areas  for  both  missions.  Selective  voice  monitoring  capa- 
bility of  the  air-to-ground  voice  link  for  either  mission  from  the 
contingency  support  area  is  provided. 

Three  separate  functional  areas  are  provided:  mission  A control 

area,  mission  B control  area,  and  a contingency  support  area  capa- 
ble of  supporting  either  mission  A or  B.  Coordination  voice  is 
provided  between  the  control  areas  and  the  contingency  support 
areas.  The  control  areas  discussed  in  this  paragraph  are  function- 
al and  need  not  be  implemented  as  separate  facilities  or  rooms. 

Each  primary  control  area  (mission  A and  mission  B)  is  configured 
with  the  normal  complement  of  operating  positions  as  defined  in 
paragraph  2.1.  These  include  the  FD,  TC,  VAO,  and  FA  (Orbiter) , 
the  VAIUS,  and  the  CCIUS.  The  STSMD  provides  overall  direction 
for  both  missions. 

Two  Orbiters  may  have  simultaneous  contact  with  the  RTS.  During 
these  periods,  only  one  mission  control  area  receives  real-time 
data,  while  the  other  area  views  recorded  data  which  is  processed 
on  an  as  required  basis.  The  determination  of  which  control  area 
is  to  view  real-time  data  is  determined  by  the  STSMD  based  on  mis- 
sion requirements,  mission  activity,  mission  status,  and  mission 
progress . 

Each  control  area  is  provided  with  the  capability  for  voice  com- 
munications with  the  Orbiter  assigned  to  their  specific  mission. 
Simultaneous  processing  of  Orbiter  voice  is  dependent  upon  the 
position  of  the  Orbiters  and  the  RTS  scheduling  constraints. 

In  addition,  a contingency  support  area  is  provided  consisting  of 
general-purpose  operating  positions  which  may  be  configured  to 
support  multiple  functions.  Only  one  mission  will  be  supported  in 
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a contingency  mode  of  operation;  the  type  of  contingency  will  dic- 
tate the  configuration.  Manning  of  this  area  is  similar  to  con- 
tingency support  for  a single  mission  discussed  in  paragraph  2.2.1. 

A voice  monitor  capability  is  provided  for  the  mission  requiring 
additional  support. 

2.3.2  Configuration  2 for  Alternate  Configuration  for  Dual  Mission 
Support"  An  alternate  support  configuration  for  dual  mission  is 
presented  in  figure  2-3.  The  addition  of  a second  applications  pro- 
cessor in  this  configuration  provides  the  following  additional 
capabilities : 

• Simultaneous  applications  processing  provided  for  mission  A 
and  mission  B telemetry  inputs  to  the  SMCC  and  command  out- 
puts from  the  SMCC 

• A backup  processor  provided  for  support  of  either  mission  A 
or  mission  B;  the  backup  processor  would  be  online  only  dur- 
ing contingency  situations 

• Mission  data  provided  to  each  mission  control  area  simul- 
taneously in  support  of  its  respective  mission. 
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SECTION  3 


ORD  SUPPLEMENT 


3 . 1 GENERAL 

Based  on  the  program  requirement  that  DOD  missions  will  be  con- 
trolled from  the  STC,  the  ORD  was  prepared  listing  the  preliminary 
requirements  the  STS  levies  on  the  USAF  SCF  in  support  of  mission 
control.  However,  the  agency  within  the  USAF  responsible  for  mis- 
sion planning  and  development,  flight  software  development,  flight 
crew  training,  and  similar  areas  has  not  been  specified.  Since 
this  may  not  be  the  SCF,  the  functions  were  identified  in  the  ORD, 
but  the  requirements  for  them  were  listed  as  TBD.  As  responsibil- 
ities for  these  functions  are  fixed,  analysis  to  determine  the 
total  requirements  on  the  SCF  (if  applicable)  can  be  conducted. 

This  section  discusses  considerations  used  in  determining  require- 
ments for  the  implementing  of  capabilities  or  rationale  concerned 
with  "TBD"  items  in  the  ORD  for  the  major  topics  of  control  and  dis- 
play, data  processing,  SMCC  communications,  the  approach  and  landing 
operations,  and  the  ephemeris  requirements.  Considerations  dis- 
cussed are  based  on  previous  experience  with  control  systems  and 
manned  spaceflight  support  and  control. 

3.2  CONTROL  AND  DISPLAY  CONSIDERATIONS 

An  SMCC  Display/Control  System  (D/CS)  (performing  in  conjunction 
with  SMCC  Data  Processing,  Communications,  Command,  and  Terminal 
Systems)  is  envisioned  for  providing  mission  and  support  personnel 
the  capability  of  requesting  and  observing  computer-generated  data 
displays.  (Refer  to  section  2.)  In  this  capability,  the  system 
will  detect,  encode,  and  transmit  console-originated  operator  re- 
quests to  the  computer  systems  and  generate  displays  in  response 
to  these  requests,  and  distribute  the  display  information  to  the 
desired  display  equipment.  Related  requirements  will  include  pro- 
vision of  a command  system  permitting  user  initiation  and  valida- 
tion of  SMCC  computer-resident  or  computer-generated  commands  prior 
to  subsequent  uplink  via  RTS. 

Based  on  previous  exposure  to  similar  systems,  the  nominal  D/CS 
will  comprise  a hardware/software  configuration  including  computer 
input/output  equipment,  television  and  digital  event  generating 
and  distributing  equipment,  and  console/group  display  equipment. 
Primary  users  of  the  D/CS  will  include  SMCC  operations  personnel 
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(comprising  flight  controllers,  network  support  personnel,  in- 
flight and  postmission  analysts,  and  development/planning  groups) 
which  will  utilize  the  system  for  premission  software/hardware 
development  and  equipment  scheduling.  Summary  requirements  levied 
on  the  D/CS  by  these  users  (requirements  establishing  minimum  D/CS 
capabilities)  will  satisfy  the  following  STS  program  applications. 
(Refer  also  to  tables  2-3,  2-4,  2-5,  and  2-6): 

• STS  mission  operations  (online) 

• STS  simulations/training 

• Postmission  data  retrieval  and  analysis 

• STS  activities  scheduling  and  planning 

• STS  program  development. 

Applications  involving  the  operations  and  inflight  mission  evalua- 
tion groups  will  include  Orbiter-generated  and  ground-base-computed 
data,  processed  and  presented  in  real-time  or  near-real-time  on 
computer  driven  D/CS  display  devices  throughout  prelaunch,  ascent, 
on-orbit  and  reentry  phases.  In  addition,  postmission  evaluation 
groups  will  utilize  post -operations-processed  data  displayed  in 
the  form  of  computer-generated  reports  and  plots. 

Development/planning  group  requirements  will  nominally  include  dis- 
plays generated  in  nonrcal-time  from  ground-base-generated  computer 
inputs,  including  predefined  simulated  data  and  recorded  mission 
data . 

3.2.1  Operational  STS  D/CS  Requirements.  The  interface,  distri- 
bution, and  end  device  equipment  provided  by  the  STS  D/CS  will 
satisfy  two  basic  user  requirements,  display  and  control,  which 
are  defined  as  follows. 

A.  Display.  Presentation  of  data  on  wall-type  projection  dis- 
plays, console-mounted  digital  readout  devices,  console- 
mounted  CRT's,  hardcopy  printers  or  recorders,  microfilm 
projection  equipment,  and  analog  devices. 
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B.  Control.  Provisions  of  manually  operable  keyboards,  thumb- 
wheels and/or  pushbutton  switches  as  required  for  access  to 
computer-resident  data,  control  of  hardcopy  and  microfilm 
facilities,  and  control  of  D/CS  configurations. 

Major  D/CS  capabilities  required  for  this  support  include: 

• Computer  input  control 

• CRT  television  generated/distribution 

• Group  television 

• Group  display  (x-y  plotters) 

• Digital  display  (console-mounted  event  lights) 

• Consoles  (multifunction  desired) 

• Telemetry  display  (event  light  similar  to  digital  dis- 
play) 

• Support  equipment  control/display  (configuration 
monitoring/ equipment  allocation) 

• Analog  displays. 

3. 2. 1.1  Operational  Data  Categories.  Expected  data  flow  to  and 
from  the  SMCC  user  areas  will  be  one  or  more  of  the  following 
categories : 

• Television  display  request,  presentation,  and  updates 

• Group  display  request,  presentation,  and  updates 

• Program  control  entry  and  verification 

• Digital  event  displays/updates 

• Analog  event  displays/updates 

• Command  entry/verification 

• D/CS  configuration  management  data  (resource  allocation). 
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3. 2. 1.2  Multifunction,  Programmable  D/CS  Considerations.  Gener- 
ally, assessments  of  requirements  for  the  operational  data  flow 
categories  listed  above  were  performed  in  light  of  a traditional 
central  computer-driven  display/control  environment,  wJ-rein  major 
end  devices  (consoles  in  particular)  are  essentially  groupings  of 
analog  devices  and/or  transducers  directly  dependent  on  the  central 
computer  for  interpretation  or  origination  of  their  inputs  and 
outputs,  respectively. 

However,  iu  recognition  of  more  recent  trends  toward  autonomous, 
programmable  distribution  and  end  devices,  each  assessment  was 
qualified  (where  deemed  applicable)  to  note  the  potential  utili- 
zation of  such  techniques.  An  example  would  be  the  assessment 
of  general-purpose  consoles  capable  of  satisfying  the  require- 
ments of  several  SMCC  control  positions  (refer  to  Section  2, 
control  positions:  Flight  Plans/Timeline,  Operations  and  Pro- 

cedures, Electrical/Environmental,  Communications /Instrumentation, 
G§N/Control) . Incorporation  of  miniprocessing  in  such  consoles 
with  the  inherent  capability  to  dynamically  reconfigure  them  in 
real-time  is  a typical  "multifunction"  consideration  which  will 
be  noted  in  subsequent  paragraphs. 

Similar  considerations,  relative  to  D/CS  data  distributors  and 
concentrators,  deal  with  programmable  communications  controllers; 
for  example,  configured  to  a central  computer  channel  but  re- 
lieving the  host  computer  of  numerous  I/O  overhead  tasks.  Major 
advantages  of  such  configurations  are  realized  particularly  in 
designs  where  existing  processing  systems  (e.g.,  existing  SCF 
Digital  TV  processors)  are  augmented  to  accommodate  expansion  with 
minimum  impact  on  the  existing  processor's  operating  systems  soft- 
ware. 


3. 2. 1.3  TV  Displays  Utilizing  a Centralized  Computer  System 

3. 2. 1.3.1  General  Data  Flow.  A TV  display  request,  for  either  a 
console  CRT  or  a projected  group  TV  screen,  will  originate  as  a 
selection  at  an  SMCC  user's  display  request  device.  The  request 
will  be  received  by  computer  input  multiplexing  equipment,  format- 
ted into  computer- language  words  and  multiplexed  into  the  SMCC  data 
processing  equipment.  The  requested  display  data  is  typically 
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output  in  computer-language  format  to  SMCC  TV  distribution  equip- 
ment for  display  video  generation  and  routing  to  the  requestor's 
designated  display  device. 

3. 2. 1.3. 2 End  Device  Requirements  and  Considerations.  Two  general 
classes  of  end  devices  are  identified  with  TV  display  requirements: 
display  request  (input)  devices  and  display  presentation  (CRT, 
projection  screen)  devices. 

A.  Display  Request  Devices.  Three  possible  methods  to  input 
user  display  requests  are  envisioned  for  the  SMCC  D/CS. 

All  are  presumed  for  implementation  as  console-resident 
devices : 

• Interactive  terminal  keyboards 

• Fixed  function  (PBI)  panels 

• Programmable  (multifunction)  panels. 

Detailed  requirements  for  each  (quantities,  locations,  elec- 
trical specifications)  are  TBD  as  noted  in  the  SMCC/STS  ORD 
(paragraph  4.10.6.1.2.1).  General  considerations  necessary 
in  determining  those  requirements,  however,  should  include: 

1.  Classes  of  Data  Input.  Direct  request  of  preprogrammed 
display  for  observation  only,  and  callup  of  display  for 
editing/modification  (program  control  entries). 

2.  Required  Display  Usage  and  Response  Times.  Number  of 
frequently  used,  real-time  display  requests,  compatible 
with  fixed  (or  programmable)  function  panels  requiring 
minimum  user-computer  interaction  for  callup,  vs  number 
of  infrequently  used,  non-real- time  display  requests 
more  compatible  with  interactive  keyboard  entry  techni- 
que. 

3 . Flexibility  of  Display  Control  Required  by  Multiple 
Users . Used  on  general-purpose  consoles.  Related  con- 
siderations should  deal  primarily  with  programmable 
display  request  panels  which  are  dynamically  reconfig- 
urable  either  from  a central  processor  or  from  a console- 
resident  miniprocessor  (refer  to  paragraph  3. 2. 1.3. 4). 
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4. 


Interface  Characteristics.  Address  codes,  function 
codes,  data  formats  multiplexing  compatibility,  and 
physical  characteristics  (signal  leve1^,  noise  sup- 
presssion  techniques,  etc.)* 

B.  Display  Presentation  Devices.  Two  methods  of  displaying 
TV  data  were  considered  for  the  SMCC  D/CS:  console-mounted 

CRT’s  and  group  TV  (projection  TV  and/or  overhead  monitors). 
Detailed  specifications  for  each  are  TBD  as  noted  in  the 
ORD.  These  specifications  will,  however,  reflect  as  a min- 
imum the  following  typical  considerations: 

1.  CRT  devices 


• Quantity  and  location 

• Number  of  selectable  channels 

• Refresh  rates 

«>  Refresh  memory  location  (computer  self-contained 
part  of  distributors/video  switchers) 

• Resolution 

• Scanning  parameters 

• Character  size 

• Alphanumeric/graphic  capabilities 

• Vector  generation  capability  (if  contained  within 
CRT  unit) . 

2 . Projection  TV  devices 

• Quantity  and  location  of  projection  screens 

• Image  size(s) 

• Type  and  number  of  rear  projectors 

• Optical  throw  distances 
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i. 

• Projector  scanning  parameters 

• Resolution 

" ’ • Interface  characteristics. 

3.  Overhead  TV  Monitors.  Considerations  will  be  similar 
to  CRT's  above,  with  added  consideration  for  tilt  an- 
gles, limited  display  capability  (e.g.,  due  to  limited 
resolution)  ambient  lighting  levels,  etc. 

3. 2. 1.3.3  TV  Data  System  Distributor/Concentrator  Considerations 

* * A.  Display  Request  Multiplexers/Input  Concentrators.  In  a 

central  computer-oriented  D/CS,  display  requests  or  display 
control  entries  are  traditionally  multiplexed  from  multiple 
console-mounted  devices  onto  the  computer  I/O  channel.  It 
uses  intermediate  equipment  to  accomplish  the  multiplexing 
and  related  format  conversion  (e.g.,  keyboard  bilevels-to- 

‘ computer  language)  and  signal  characteristics  conversion 

(levels,  rise  times,  etc.).  As  noted  in  the  ORD,  detailed 
requirements  relative  to  this  equipment  are  TBD . System 
considerations  necessary  to  determine  those  requirements 
will  include  the  following: 

1.  Number  of  input  (display  request)  devices  to  be  serviced. 

2.  Required  response  time  to  user-related  considerations; 
for  example,  re'"  ired  multiplexing  speeds,  multiplexer 
buffering  requirements,  priority  request  requirements, 
and  computer  channel  data  rate  requirements. 

3.  Resource  allocation  such  as  priority  switching  of  multi- 
plexing capabilities  to  critical  users  via  program  con- 
trol or  manual  control. 

4.  Critical  path  availability,  such  as  redundancy,  reli- 
ability, automatic  failover  to  backup  channels,  etc., 
particularly  for  real-time  users. 

5.  Interface  characteristics,  such  as  computer  channel  data 
handling  conventions  and  electrical  interface  specifi- 
cations . 
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B.  TV  Data  Distribution.  Determination  of  distribution  re- 
quirements for  TV  data  will  nominally  involve  the  following 
considerations : 

• Computer  language- to-video  conversion  techniques 

• Routing  and  video  switching  techniques 

• Quantity  and  quality  of  output  video  channels  required 

• Resource  allocation  control,  such  as  remote  manually  or 
switchable  program-controlled  allocation  of  channels  to 
various  users 

• General  interface  characteristics,  such  as  computer  chan- 
nel data  handling  conventions,  electrical  interface  char- 
acteristics, refresh/update  rates,  etc. 

3. 2. 1.3.4  Assessment  of  Multifunction  TV  System  Capabilities 

A.  Miniprocessors  in  Consoles.  Determination  of  actual  user 
end  device  (CRT,  display  request  input)  implementation 
should  reflect  the  assessment  of  capabilities  realized 
from  data  processing  contained  within  the  user's  console, 
(e.g.,  miniprocessors).  Two  particular  considerations 
should  include  the  following: 

1.  Reconfiguration  Flexibility.  In  instances  where  a 
given  general-purpose  console  may  serve  multiple  users 
(non- simultaneous ly) , rapid  reconfiguration  of  the 
console  would  be  desirable.  A nominal  method  for  im- 
plementing this  capability  would  be  to  provide  essen- 
tially "blank  legend"  consoles  with  self-contained 
applications  software  (selectable  by  the  user  via  key- 
board function  code  entry)  driving  the  console's  legends, 
event  lights,  etc.,  in  correspondence  to  the  desired 
support  function. 

2.  Offline  Development  Compatibility.  Residence  of  display 
applications  software  within  a user's  console  inherently 
reduces  his  requirement  for  online  display/request/ 
generation  transactions  with  centralized  computer  sys- 
tems (a  feature  which  not  only  increases  his  own  response 
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time  but  more  desirably,  reduces  time-consuming  I/O 
overhead  in  the  central  system).  For  offline  program 
development  (mission  planning,  simulations,  program 
development)  this  feature  could  prove  quite  feasible. 

A particular  advantage  can  be  seen  if  the  SMCC  D/CS 
data  processing  capabilities  were  implemented  as  an 
augmentation  of  the  existing  STC;  i.e.,  any  new  unique 
interface  handling  software,  applications  handling, 
etc.,  could  possibly  be  assumed  to  a large  extent  by 
the  console-resident  software.  Note:  For  fixed  func- 

tion consoles  (section  2)  programmable  console  features 
do  not  appear  to  have  equivalent  advantages , but  do 
merit  similar  consideration. 

B.  Programmable  Data  Concentrators/Distributors.  A require- 
ment of  traditional  TV  distribution  systems  (distributors/ 
concentrators)  is  to  provide  compatibility  with  computer 
channel  data  handling  conventions  (access  method  functions, 
transmission  control  functions),  in  addition  to  performing 
computer- language- to-video  conversion,  multiplexing  display 
request  inputs,  etc.  A major  constraint  associated  with 
the  computer  interface  is  the  I/O  line  handling  responsi- 
bility assumed  by  the  computer's  access  method  software. 
Programmable  I/O  controllers  (divorced  from  total  dependence 
on  the  computer's  access  software,  and  implemented  as  part 
of  the  D/CS  distribution)  appear  to  be  one  method  of  re- 
lieving such  constraints,  and  should  be  considered  in  deter- 
mining detailed  SMCC  D/CS  requirements.  Desirable  features 
of  these  controllers  would  include  the  following. 

1.  Flexibility.  A given  controller  can  be  programmed  to 
interface  distribution  systems  other  than  TV  (e.g., 
digital  event  distribution)  on  a time-shared  basis, 
resulting  in  decreased  numbers  of  dedicated  (fixed- 
function  by  hardware)  controllers  for  each  type  of  data 
distribution.  Variable  scan  rates  and  formats  are  re- 
lated features. 

2.  Reduction  of  Central  Processing  Unit  (CPU)  I/O  Overhead. 
Programmabl  I/O  controllers  nominally  assume  the  line 
handling  responsibilities  between  the  computer  and  the 
display  network,  relieving  the  computer  of  this  high 
overhead  requirement. 
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3.  Compatibility  with  Augmented  Systems.  In  the  case 

where  an  existing  system  (e.g.,  SCF)  would  be  augmented 
to  incorporate  a new  system  (e.g.,  SMCC  D/CS),  the  capa- 
bility to  program  the  "existing-computer- to-new  system" 
interface  using  standalone  programmable  controllers 
offers  distinct  advantages;  the  major  one  is  reduction 
in  modifications  to  existing  I/O  software.  This  advan- 
tage should  be  evaluated  in  final  determination  of  the 
D/CS  requirements. 

3. 2. 1.3. 5 TV  Display  Hardcopy  Considerations.  SMCC  personnel 
viewing  a TV  monitor  display  or  projection  TV  display  typically 
desire  the  capability  to  hardcopy  to  given  display  by  initiating 
a hardcopy  request  from  their  console.  Nominally,  the  identity 
and  location  of  the  requestor  will  be  transmitted  with  the  input 
request  to  hardcopy  control  circuits,  as  switching/routing  control 
data.  Subsequent  switching  of  the  desired  video  channel  to  hard- 
copy recorder  equipment  will  accomplish  the  required  image  con- 
version. In  addition  to  the  requested  display  data,  the  resulting 
hardcopy  also  includes  time-tagging,  superimposed  on  the  print. 
Specific  hardcopy  requirements  are  TBD  as  noted  in  the  ORD,  (para- 
graph 4.10.6.1.2.2).  Typical  assessments  or  considerations  to  be 
made  in  determining  those  requirements  will  include  the  following. 

• Type  of  Hardcopy  Medium,  e.g.,  thermic  or  electrolytic  photo- 
graphic ink  jet,  direct  pen,  electrostatic,  line  printer 

• Resolution 

• Quantity  and  Access  Methods 

• Interfaces , e.g.,  console,  computer  channel,  video  converter, 
video  channel  switcher,  etc. 

• Methods  of  Output  Distribution,  e.g.,  pneumatic  tube,  hand- 
carry. 

3.2.1  3.6  TV  Display  Program  Development.  Refer  to  paragraph 
3.2. 

3. 2. 1.4  Group  Display  Considerations.  Large-screen  projection 
plotting  and  X-Y  plotters  are  the  two  categories  of  group  displays 
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envisioned  for  the  SMCC.  Detailed  requirements  for  each  are  TBD 
as  noted  in  the  ORD;  general  considerations  are  discussed  in  the 
following  paragraphs. 

3. 2. 1.4.1  Projection  Plots.  Large-screen  projection  plotting  dis- 
plays nominally  originate  as  selections  from  operator's  consoles. 
The  selection  data  is  converted  to  computer- language  format  and 
multiplexed  into  the  computing  facilities.  The  computer(s)  output 
the  associated  preprogrammed  display  data  in  computer- language 
format  to  plotting  display  data  distribution  equipment.  Subsequent 
display/control  processing  includes  conversion  of  the  computer- 
language  data  to  control/distribution  data  for  routing  to  plotting 
display  equipment.  Plotting  equipment  (nominally  analog)  generates 
the  display  in  a manner  suitable  for  projection  onto  large  display 
screens  in  the  designated  area(s).  Following  initial  activation 
of  the  display,  any  preprogrammed  updates  are  nominally  output  from 
the  computer  to  the  group  display  equipment  without  operator  inter- 
vention. 

Requirements  considerations  for  this  display  capability  will  in- 
clude : 

A.  Input  Request  Multiplexing/Data  Concentration.  Considera- 
tions will  be  similar  to  those  specified  for  TV  display 
requests  in  paragraph  3. 2. 1.3.3;  i.e.,  multiplexing,  re- 
formatting (console  input-to-computer  language,  electrical 
interface  compatibility,  etc.). 

B.  Output  Distribution.  Output  distribution  of  projection 
plotting  data  will  require  assessment  computer- language- 
to-analog  plotting  data  conversion,  address  routing  decod- 
ing, electrical  interface  compatibility,  and  ultimate  pres- 
entation on  plotting  screens. 

C.  End  Devices.  Methods  for,  and  consideration  of,  projection 
plot  request  devices  will  be  similar  or  identical  to  those 
candidates  envisioned  for  TV  display  requests  defined  in 
paragraph  3. 2. 1.3. 2 (i.e.,  interactive  terminal,  fixed  func- 
tion keyboard,  programmable  function  panel,  etc.).  An  ex- 
ception may  be  preprogrammed  plots  which  are  automatically 
displayed  and  updated  in  real-time  in  certain  mission 
phases  (e.g.,  trajectory  plots). 
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Requirements  for  the  plotting  display  presentation  will  be 
determined  from  the  following  (typical)  considerations: 

• Screen  size(s)  and  quantities 

• Number  and  type  of  scribing  projectors  required 

• Static  background  projection  requirements 

• Symbol  generation  requirements 

• Control  electronics. 

3. 2. 1.4. 2 X-Y  Plotboard  Displays.  X-Y  plotboards  in  the  SMCC  are 
envisioned  for  presenting  trajectory  plotting  data  received  in 
downlink  telemetry  data  and  processed  in  a preprogrammed  sequence 
for  presentation.  SMCC  display/control  processing  for  X-Y  plotting 
will  include  real-time  interpretation  of  the  telemetry  parameters, 
with  subsequent  generation  and  output  of  the  X-Y  data  in  computer- 
language  format  to  required  distribution  equipment. 

Detailed  X-Y  plotting  requirements  will  be  determined  from  the  fol- 
lowing (typical)  considerations: 

• Plotboard  quantities,  types,  and  locations 

• Amount  of  downlink  telemetry  data  to  be  displayed 

• Display  formats  required 

• Computer  language- to- analog  plotboard  value  conversion  tech- 
niques 

• Manual  control  (if  required;  nominally  these  plots  are  gen- 
erated in  a preprogrammed  manner  with  no  operator  interven- 
tion) . 

3. 2. 1.5  Program  Control  Entry/Verification.  Program  control  entry 
considerations  for  the  SMCC  D/CS  encompassed  the  following  user 
entry  functions: 

• Display  Request.  CRT,  group  display 
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• Command  Control.  Set  up,  enable/disable/transmit 

• Program  Modification.  Display  callup  for  edit/modification, 
program  development  (nominally  offline) 

• Console  Reconfiguration.  If  performed  by  software,  these 
entries  could  be  to  either  a central  processor  or  a console 
resident  miniprocessor. 

Entries  will  originate  at  operator's  consoles  in  SMCC  user  areas. 

The  data  will  nominally  be  converted  to  computer  language  and  mul- 
tiplexed into  the  SMCC  computers.  The  computer  will  verify  an 
entry  by  illuminating  an  event  light  (s)  at  the  position  from  which 
original  entry  was  made.  The  data  flow  for  this  process  will  require 
the  computer  to  output  computer  language  data  to  digital  display 
distributors  for  decoding  the  desired  input  location  and  activat- 
ing the  corresponding  digital  verification  display. 

3. 2. 1.5.1  Entry  Device  Considerations.  The  types  of  devices  con- 
sidered for  program  control  entry  are  those  listed  previously  for 
TV  and  group  display  request,  including: 

• Interactive  terminal  keyboard 

• Fixed  function  PBI  panel 

• Programmable  function  PBI  panel. 

A.  Interactive  Terminal  Keyboards.  An  interactive  (with  com- 
puter)  keyboard  is  envisioned  for  many  console  positions  in 
the  SMCC.  Detailed  requirements  are  TBD  as  noted  in  the 
ORD.  However,  general  considerations  for  determining  these 
requirements  will  include: 

• Cursor  controls 

• Alphanumeric  entry  requirements 

• Graphic  control  requirements 

• Special  function  codes 

• Special  CRT  display  editing  controls,  such  as  erase  line, 
erase  page,  delete,  insert,  etc. 

• Light-pen/cursor  compatibility 
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• Interfaces  such  as  CRT,  central  computer,  local  computer 
(miniprocessor),  direct  closed-loop  to  console  event 
lights . 

These  typical  considerations  are  relative  to  the  keyboard 
device  itself.  Related  major  considerations  are  provision 
of  interactive  terminal  processing  software  in  the  central 
computer (s),  (refer  to  paragraph  3.2)  and  any  special  ter- 
minal communications  data  concentrators  required  between 
the  central  computer  and  the  keyboards. 

For  applications  involving  console-resident  software  (mini- 
processor), considerations  must  deal  primarily  with  keyboard 
interface  software,  related  console  event-light  software 
(e.g.,  keyboard  entry  verification)  and  CRT  display  gener- 
ation response  to  keyboard  entries. 

B.  Fixed  Function  Panels.  Fixed  function  panels  envisioned 
for  the  SMCC  D/CS  will  be  console-mounted  PBI  (pushbutton- 
indicators)  or  event  light  (illumination  only)  arrays.  The 
fixed  function  designation  refers  to  the  fact  that  a given 
PBI  or  event  light  provides  one  and  only  one  function  (in- 
put or  event  indication)  for  any  user,  as  opposed  to  a pro- 
grammable panel,  whose  input  or  output  function  may  be 
modified  dynamically  under  software  control  (refer  to  para- 
graph 3 . 2 . 1 . 5. 1 ,C) . 

General  design  considerations  relative  to  fixed  function 
panels  will  include  (typically): 

• Number  of  fixed  entry  parameters  required 

• Number  of  fixed  event  indications  required 

• Interfaces  within  the  console,  to  external  data  concen- 
trators, or  to  distributors 

• Program  development  requirements  (refer  to  paragraph 
3.2). 

C.  Programmable  Function  Panels.  While  the  CRT's/keyboard  are 
considered  the  primary  means  of  display  and  control  at  a 
console,  and  may  be  all  that  is  required  in  many  fixed  con- 
sole applications,  "programmable  function  panels"  may  be  a 
desirable  supplement  to  them,  particularly  in  the  case  of 


3-14 


general-purpose  consoles.  Their  use  will  be  determined  by 
the  operator  and  controlled  by  his  application  programs. 

These  panels  are  normally  conceived  as  "blank  legend"  event 
light  or  PBI  panels;  each  panel's  function  is  determined  by 
either  local  (console-resident  processor)  or  remoted  central 
processor  software.  Their  utilization  requires  an  operator 
setup  entry  (e.g.,  via  an  associated  console  keyboard  or 
fixed  function  panel)  to  select  and  activate  the  required 
functional  software. 

Considerations  which  will  determine  detailed  requirements 
for  these  panels  will  include  utilization  of  consoles 
(general-purpose  in  particular).  These  considerations  must 
deal  with  needs  for  rapid  reconfiguration  of  and  function- 
al flexibility  of  various  console  panels.  If  determined 
to  be  a desirable  feature,  the  following  considerations  must 
be  undertaken. 

• Alphanumeric  capabilities 

• Response  times 

• Program  location  and  complexity 

• Special  effects  (blinking,  scrolling) 

• Program  setup  techniques 

• Physical  properties  such  as  size,  quantities,  and  loca- 
tions . 

3. 2. 1.6  Digital  Event  Displays.  Digital  event  display  data 
(event  lights ) activated  on  occurrence  of  preprogrammed  events 
normally  occurs  without  operator  intervention.  Detailed  require- 
ments for  generation  and  routing  of  those  preprogrammed,  automat- 
ically invoked  displays  are  TBD  as  noted  in  the  ORD.  Determination 
of  those  requirements  will,  however,  necessitate  the  following  con- 
siderations . 


3. 2. 1.6.1  Distribution  Considerations . Digital  events  may  originate 
either  in  a console-resident  or  central  computer  processor.  In  the 
latter  case,  distribution  requirements  will  be  concerned  with 
computer-language-to-analog  device  activation  signals  (lamp  driver 
voltage  conversion,  address  routing  decoding,  and  distribution  of 
event  light  power  to  the  required  end  device) . Associated  design 
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considerations  will  include  redundancy  for  critical  event  paths 
and  programmable  distributor  applications  (refer  to  paragraph 
3 . 2 . 1 . 3 . 3 ) . 

For  those  digital  event  indications  emanating  from  console-resident 
miniprocessors  (if  applicable),  distribution  requirements  would  be 
reduced  significantly  in  that  they  would  be  limited  to  "design  con- 
siderations within- the-console"  in  most  cases,  wherein  reduced  de- 
code, conversion,  and  driver  design  problems  are  obvious. 

3. 2. 1.6. 2 Digital  Event  End  Device.  Actual  digital  event  indica- 
tions nominally  occur  as  illuminations  of  some  end  device  on  a 
console  or  group  display.  For  console  event  indications,  the  fixed 
function  or  programmable  function  panels  previously  mentioned  will 
in  most  liklihood  be  used.  Considerations  relative  to  determining 
their  detailed  requirements  (noted  as  TBD  in  ORD)  are  the  same  as 
for  the  panels  themselves,  i.e.,  alphanumeric  capabilities,  rear- 
projection  back- 1 ighting , light  emitting  diodes  (LED's),  update 
rates,  etc. 

3. 2.1.7  Analog  Event  Display/Control.  The  D/CS  is  envisioned 
as  requiring  analog  displays  presented  on  analog  stripchart  re- 
corders and  bilevel  event  recorders. 

3. 2. 1.7.1  Analcg  Stripchart  Recorders.  Analog  stripchart  record- 
ers arc  normal  1)  utilized  as  a primary  means  of  displaying  control 
position  and  vehicle  response  data.  In  addition,  the  recorders 
may  be  required  for  recording  selected  Orbiter  systems  data.  De- 
tailed requirements  for  the  stripchart  recorders  are  TBD  as  noted 
in  the  ORD.  Those  requirements  will  be  established  from  consider- 
ations including: 

• Number  of  events  to  be  stripped  from  the  downlink  telemetry 
streams  and  the  associated  processing  requirements  for  con- 
version from  digital - to-analog 

• Trace  amplitudes 

• Number  of  recorder  channels/per  unit 

t Quantity/ location  of  recorder. 

3. 2. 1.7. 2 Bilevel  Event  Recorders.  Bilevel  event  recording 
equipment  consists  of  fixed  stili  information  recording  on  mov- 
ing charts,  and  are  generally  used  for  recording  of  bilevel 
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engineering  events  and  for  biomedical  parameters  stripped  from  the 
telemetry  downlink.  Detailed  requirements  are  TBD  as  noted  in  the 
ORD.  Considerations  relative  to  determining  those  requirements 
will  include: 

• Signal  resolution 

• Chart  speeds/regulation 

• Interfaces,  [i.e.,  telemetry  ground  stations  and  digital-to- 
analog  converters  (DAC's)] 

• Locations/quantities. 

3 . 2 . 1 . 8 Command  Control  Entry/Verification  Considerations.  Command 
control  entries  are  envisioned  for  the  SMCC  D/CS  as  switch  closures 
originating  at  SMCC  user's  consoles.  The  switch  closure  signals 
will  be  received  by  computer  input  multiplexing  equipment,  format- 
ted into  computer  language,  and  multiplexed  into  the  SMCC  computers. 
Subsequent  action  by  the  computer  programs  will  extract  the  se- 
lected command  from  predefined  storage  and  output  it  to  a predes- 
ignated remote  site. 

Verification  of  command  entries  will  require  computer  language  data 
containing  the  identity  of  the  originating  location  to  be  output  by 
the  SMCC  computer  to  distribution  equipment  for  decoding  and  acti- 
vation of  an  appropriate  digital  display  driver,  completing  the 
entry  verification  by  lamp  illumination  (event  light). 

Requirements  for  command  control  systems  in  the  SMCC  D/CS  will  be 
derived  from  the  following  considerations. 

3. 2. 1.8.1  End  Devices  (Input  and  Verification) . These  consider- 
ations are  essentially  the  same  as  those  defined  for  program  con- 
trol and  event  indication  devices  in  paragraphs  3. 2. 1.5  and 

3. 2. 1.6. 

3. 2. 1.8. 2 Command  Data  Processing.  Major  considerations  for 
command  control  requirements  determinations  will  be  the  data  flow 
processes  associated  with  their  generation  and  execution.  These 
considerations,  discussed  in  paragraph  3.5,  are  summarized  here 
to  emphasize  their  implications  relative  to  D/CS. 

A.  Command  Generation  Processing.  The  command  generator  should 
be  responsive  to  both  manual  and  automatic  requests  (where 
indicated) . 
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• Generates  command  data  updates  for  transmission  to  the 
RTS 

• Formats  data  into  blocks  identified  by  site  and  trans- 
fers data  to  the  prepass  data  file 

• Recognizes  designated  levels  of  constraint  violation  and 
responds  according  to  mission  rules 

• Provides  indications,  as  prescribed,  during  the  command 
generation  process 

• Sets  the  real-time  update  flag,  if  there  is  a need  to 
generate  commands  for  a station  during  vehicle  contact. 

B.  Command  Execute/Modify/Review  Processing.  Command  execute/ 
modify/review  programs  should  provide  for  the  direct  up- 
link of  commands  to  the  Orbiter  from  the  SMCC  flight 
and  mission  controllers.  These  programs  should  include 
the  following  functions: 

• Provide  for  online  inputs  from  the  controllers  to  allow 
execution  and  review  of  the  scheduled  commands 

• Execute  a real-time  modified  command  (modified  after  the 
prepass  command  load  update)  in  place  of  the  prepass  up- 
dated command 

» Recall  commands  in  the  currently  scheduled  RTS  command 
load  for  review,  or  display  a log  of  the  commands  trans- 
mitted to  the  RTS 

• Format,  by  command  execute  subprograms,  the  RTS  com- 
mand index  number  of  the  real-time  modified  command  with 
the  site  ID,  and  set  command  message  ready  flag  for  the 
communications  subprogram. 

• Display  the  command  execute  status  to  the  controller  who 
executed  the  current  command  when  the  communications  sub- 
program transmits  the  command  to  the  site  (the  command 
capability  is  distributed  to  a number  of  controllers,  in 
line  with  their  functional  responsibility) 

• Display  the  Orbiter  command  action  status  to  the  appro- 
priate controller  upon  receipt  of  a command  validate 
message  from  the  RTS,  or  indication  of  an  excess  response 
time  interrupt 
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• Record  a history  of  the  command  and  status  of  the  re- 
sponse (by  the  command  execute  subprogram) . 

3 . 2 . 1 . 9 D/CS  Configuration  Management/Equipment  Support  Consider- 
ations . SMCC  D/CS  equipment  will,  based  on  knowledge  of  existing 
systems,  require  configuration  control,  maintenance  and  perform- 
ance evaluation  elements.  The  support  requirements  determining 
their  scope  and  complexity  will  reflect  consideration  of  the 
following  support  functions: 


• Monitoring  computer  system  selection  (online  to  backup)  as 
related  to  D/CS  equipment 

• Performing  maintenance  functions  on  D/CS  equipment  while 
maintaining  predefined  systems  availability 

• Monitoring  (within  certain  critical  areas  of  the  D/CS  trans- 
mission errors,  data  dropouts,  and  data  loss  conditions 

• Manually  assigning  components  and/or  selection  to  redundant 
components,  where  provided,  to  enhance  system  reliability. 


3.3  DATA  PROCESSING 


3.3.1  Minimum  Requirements.  Data  processing  discussed  in  this 
paragraph  represents  a basic  core  of  minimum  capabilities  required 
by  the  STC  to  satisfy  STS  monitor  and  support  functions.  These 
requirements  have  been  derived  from  implied  or  directly  stated 
requirements,  or  are  considered  logical  extensions  of  those  dis- 
cussed in  current  STS  requirements  documents . 

The  detailed  requirements  of  the  software  capabilities  described 
below  are  defined  in  the  STS  ORD,  paragraph  4.13. 

A.  Front-End  Software.  Software  is  required  to  identify  the 
source  of  data  inputs  (Orbiter,  satellite  and/or  IUS) , and 
the  type  of  data  (commands,  telemetry)  and  pass  the  data  to 
appropriate  processor  modules.  This  software  may  also  per- 
form data  conversion/calibration,  input  message  validation, 
and  interface  message  formatting  prior  to  routing  inputs  to 
other  processors. 

B.  Data  Base  Management.  Software  is  required  for  data  base 
definition,  security,  storage,  retrieval,  maintenance,  and 
interface  message  processing  with  data  input  application 
programs. 

C.  Displays . Software  is  required  to  provide  both  requestable 
and  forced  console  CRT  displays.  Both  alphanumeric  and 
graphic  display  capabilities  are  required  to  satisfy  nominal 
mission  status  monitoring  and  contingency  support  require- 
ments. Required  capabilities  include  software  for  construc- 
tion and  storage  of  display  skeletons,  display  request 
recognition/interpretation,  display  retrieval  and  console 
routing,  dynamic  data  updating  of  selected  displays,  and  a 
paging  capability  for  multipage  displays. 

D.  Limit  Sensing/Alarm  Generation.  Software  is  required  to 
perform  limit- sensing  of  critical  vehicle  and  crew  health 
status  parameters.  Required  capabilities  shall  include 
recognition  of  candidate  parameters  upon  data  receipt,  com- 
parison of  values  received  with  predefined  value  ranges, 
maintenance  of  bad  value  counts  to  determine  an  out-of-range 
condition,  forced  message  make-up  and  appropriate  console 
address(es)  routing,  and  interface  with  display  software  to 
pass/clear  forced  alarm  messages. 
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E.  Keyboard  Processor.  Software  is  required  to  process  con- 
sole keyboard  inputs  for  display  and  function  execution 
requests.  Required  capabilities  shall  include  request  val- 
idation, input  error  message  generation,  display  retrieval, 
function  execution  request  linkage  with  appropriate  appli- 
cation software  and  display/function  output  console  routing. 
Additional  requirements  include  keyboard  capabilities  to 
freeze  (and  release)  dynamic  data  updating  of  a presented 
display,  acknowledge  forced  caution  and  warning  (C§W)  dis- 
plays, selectively  modify  initialized  parameter  constants 
presented  in  CRT  displays,  suppress  C$W  alarm  routing  to  a 
specified  console  position,  display  keyboard  inputs  in  a 
CRT  reserved  "scratch  pad"  area,  and  modify/correct  dis- 
played keyboard  inputs  anytime  prior  to  request  completion. 

F.  Commands  Generation.  Software  s required  for  command  selec- 
tion, construction,  and  transmission  through  a specified  RTS. 
Requirements  include  capabilities  to  construct,  store,  and 
selectively  retrieve  both  "canned"  commands  and  command 
"shells."  Keyboard  and  CRT  display  interface  aids  are  re- 
quired for  command  selection  and  to  provide  a means  whereby 
variable  parameter  data  may  be  input  to  complete  construc- 
tion of  command  shells. 

G.  Peripheral  Processors.  Software  is  required  for  access  to 
the  peripheral  devices'  I/O  services.  Device  handlers  are 
required  for  input  processing  from  card  reader  and  magnetic 
tape  units,  and  to  direct  outputs  to  card  punch,  line  print- 
er, and  magnetic  tape  units. 

H.  Miscellaneous  Functions 


1.  Time  Display.  Software  is  requiiod  for  dynamic  display 
presentation  of  both  GMT  and  GET.  The  SMCC  time  dis- 
plays shall  be  updated  once  per  second  to  reflect  both 
GMT  and  GET  times  in  hours,  minutes,  and  seconds. 

2.  Mission  Replanning.  This  software  is  required  to  sup- 
port contingency  situations  which  necessitate  changes 
to  initialized  mission  planning  data.  This  function 
shall  be  invoked  as  a background  application  upon  con- 
sole keyboard  request  and  shall  include  keyboard/display 
software  capabilities  necessary  to  selectively  modify/ 
recalculate  any  mission  planning  parameter  (s) . 


3.  Trend/Analysis . This  function  provides  the  capability 
to  project/predict  specific  subsystem  parameter  values 
based  on  current  or  history  value  inputs  and  rate  of 
consumption/degradation  over  a specified  timeframe. 

This  function  would  be  library-resident  and  invoked  for 
background  execution  upon  keyboard  request  from  an 
authorized  console  position.  A series  of  displays  and 
keyboard  actions  shall  provide  capabilities  to  specify/ 
select  parameter  and  time  value  inputs  and  present  re- 
sultant data  in  CRT  displays.  (Data  results  may  prove 
useful  as  inputs  to  the  mission  replanning  functions.) 

4.  Log/Delog.  This  utility  is  especially  useful  as  a de- 
bug aid  during  system  development  and  checkout.  The 
utility  can  also  be  used  as  a personnel  training  aid  or 
for  selective  recording  and  processing  of  data  of  pecul- 
iar interest  during  a mission.  Selective  data/console 
action  logging  shall  be  invoked  and  terminated  by  a 
computer  operator  upon  direction  from  authorized  mission 
personnel.  The  delog  utility  is  required  for  processing 
and  line  printer  output  generation  of  all  or  a selected 
portion  of  logged  data.  Logging  shall  execute  as  a back- 
ground application  in  the  online  computer  system.  The 
delog  utility  shall  execute  as  a batch  program  in  either 
an  offline  computer  or  the  online  system,  based  on  avail- 
ability of  required  system  resources. 

5.  Data  Reduction/Statistics.  Software  is  required  to  pro- 
vide (TRD)  statistics  and  summary  report  outputs  on 
specified  parameter  data.  This  software  shall  consist 
of  a pool  of  selectable  data  reduction  routines  which 
execute  as  batch  processors.  Required  mission  data  base 
dumps  shall  be  loaded  into  a "history"  data  base  which 
then  serves  as  the  data  source  for  processing  by  selected 
statistics/summary  output  routines. 

6.  Performance  Evaluation.  Software  is  required  for  data 
collection  and  report  generation  of  system  performance 
statistics.  Data  collection  of  selected  parameters 
(e.g.,  CPU  utilization,  idle  time,  I/O  channel  utiliza- 
tion, etc.)  shall  be  performed  in  background  and  output 
to  a system  log  tape.  Report  generation  software  shall 
execute  as  a batch  processor  and  present  report  outputs 
of  logged  data  on  the  line  printer. 
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3.3.2  Optional  Capabilities.  Although  not  categorized  as  firm 
requirements,  the  following  capabilities  are  considered  highly  de- 
sirable to  augment  those  defined  in  paragraph  3.3.1. 

A.  COM.  Computer  Output  to  Microfilm  (COM)  systems  are  ex- 
tremely useful  in  any  system  designed  to  process  large 
amounts  of  data.  Today's  COM  systems  typically  accept  a 
variety  of  data  input  rormats  with  minimal  restrictions  as 
to  data  block  sizes,  special  COM  control  characters,  etc. 

A COM  system,  together  with  microfilm/microfiche  viewers/ 
hardcopiers,  provides  data  output  storage  condensation  and 
a means  by  which  multiple  copies  of  outputs  can  easily  be 
obtained  whenever  required. 

B.  Tape  Indexing.  A tape  indexing  system  is  extremely  useful, 
if  not  a necessity,  in  any  system  which  requires  a sizable 
magnetic  tape  library  for  retention  of  data.  A tape  index- 
ing system  provides  a means  by  which  the  appropriate  (set 
of)  magnetic  tape(s)  containing  data  of  interest  can  quickly 
be  retrieved.  This  capability  is  basically  a software  rou- 
tine which  extracts  required  descriptive  information  from 
data  tapes  and  produces  a report  output  correlating  data 
descriptions  with  assigned  reel  numbers.  (A  report  on  data 
base  dump  tapes,  for  example,  may  consist  of  an  ordered 
list  with  data  base  number/name,  dump  date/time,  data  start/ 
stop  frames,  and  magnetic  tape  reel  number  for  each  tape 
processed. ) 

C.  Checkpoint . The  need  for  a checkpoint  capability  is  pri- 
marily based  on  recovery  requirements  in  the  event  that  a 
hardware  failure  results  in  an  unrecoverable  loss  of  mission 
data  bases.  This  capability  is  probably  not  required  if  the 
following  statements  are  valid: 

1.  Periodic  dumps  of  critical  mission  data  bases  to  mag- 
netic tape  are  scheduled  throughout  a given  mission. 

2.  In  the  event  of  a hardware  failure  of  this  type,  criti- 
cal data  bases  can  be  reconstructed  from  dump  tape  in  a 
reasonably  short  amount  of  time  (e.g.,  30  minutes  or 
less) . 


An  unsuccessful  recovery  (data  base  reload)  attempt  will 
not  jeopardize  the  success  of  a mission. 
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If  the  above  statements  are  invalid,  a checkpoint  capability  may 
become  a firm  requirement.  The  capability  primarily  consists  of 
a disk-to-disk  copy  utility  which  permits  rapid  failure  recovery 
through  replacement  of  a "destroyed”  disk  with  its  most  recent 
copy. 
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3.4  APPROACH  AND  LANDING 

The  active  role  of  the  mission  agent  during  the  landing  operations 
and  the  landing  site/MCC  interaction  are  not  clearly  defined  at 
the  program  level;  lienee  the  reason  for  the  "TBD's"  in  the  STS  ORD, 
paragraph  4.5,  "Approach  and  Landing  Requirements,"  concerning 
landing  site/SCF  coordination  and  TAF.M  assistance. 

The  objective  of  TAEM  is  to  place  the  Orbiter  in  a favorable  posi- 
tion to  intercept  the  final  landing  approach  plane  at  the  correct 
altitude  and  speed,  and  the  start  of  TAEM  is  the  final  decision 
point  for  choosing  the  direction  of  landing.  The  Orbiter  will  have 
the  capability  to  autonomously  perform  navigation  during  entry  and 
landing,  but  it  is  a NASA  Level  II  requirement  (Vol.  18,  JSC  07700, 
paragraph  3.4.11)  that  the  mission  operations  computers  provide  the 
capability  to  perform  backup  navigation  for  the  Orbiter  during  that 
period  and  the  capability  to  uplink  ephemeris  data  as  required  to 
assure  that  safe  landing  approach  conditions  are  achieved.  Only 
when  the  specific  onboard  functions  for  performing  TAEM  have  been 
defined  can  the  SMCC  requirements  for  backup  TAEM  assistance  be 
specified. 

Another  area  of  concern  is  the  mission  control  - 1 and ing  area  opera- 
tions and  coordination  associated  with  the  approach  and  landing 
operations.  Although  Level  I and  II  requirements  are  clear  that 
the  mission  agent,  through  the  MCC  or  SMCC,  retains  control  of  the 
mission  until  the  Orbiter  comes  to  a stop  on  the  runway,  the  re- 
sponsibilities of  the  personnel  at  the  Landing  Operations  Area 
(LOA)  are  not  clear.  For  example,  the  KSC  Station  Set  Requirements 
Document,  Vol.  17,  "Landing,"  19  July  1974  states,  "The  personnel 
responsible  for  Orbiter  landing  operations  at  KSC  will  be  located 
at  consoles  in  the  LOA."  One  such  console  is  for  the  KSC  Landing 
Operations  Director.  Since  VAFB  STS  systems  and  procedures  will 
be  adapted  from  the  KSC  Shuttle  ground  systems  and  procedures,  it 
is  highly  likely  that  there  will  b a VAFB  Landing  Operations  Di- 
rector. His  functions  must  be  defined  before  the  SCF  requirements 
to  support  approach  and  landing  can  be  specified  for  VAFB  landings 
of  cither  DOD  or  NASA  flights.  Similarly,  the  KSC  Landing  Opera- 
tions Director  functions  must  also  be  defined  before  the  SCF  re- 
quirements in  support  of  KSC  landings  of  DOD  flights  can  be  speci- 
fied. 
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3.5  EPHEMERIS 


Ephemeris  requirements  contained  in  paragraph  4.8  of  the  STS  ORD 
do  not  specify  the  accuracies  required,  the  time  intervals  for  the 
ephemeris,  or  the  coordinate  system  to  be  used.  In  addition,  the 
ephemeris  is  extended  to  include  the  Orbiter's  expected  position 
vector  and  velocity  during  atmospheric  flight  (until  start  of 
TAEM) . 

The  extension  of  the  ephemeris  for  this  program  is  required  to  ac- 
quire the  Orbiter  subsequent  to  blackout  in  order  to  provide  backup 
navigation  and  landing  assistance  and  voice  communications  between 
the  SMCC  and  the  Orbiter  crew. 

Ephemeris  interval  and  accuracy  requirements  are  expected  to  evolve 
as  the  program  develops,  the  test  programs  are  conducted,  and  the 
results  are  evaluated. 

A standard  set  of  coordinate  systems  for  the  Space  Shuttle  is  to 
be  established.  This  set  will  comprise  the  minimal  number  of  coor- 
dinate systems  required  for  the  practical  exchange  of  data.  Cur- 
rently, NASA  in  JSC  Internal  Note  No.  74-FM-15,  Candidate  Coordinate 
Systems  for  the  Space  Shuttle  Program,  lists  a set  of  26  candidate 
coordinate  systems  and  states  the  final  set  will  be  developed  in 
this  calendar  year  and  recommended  as  the  standard  set  of  coordi- 
nate systems  for  the  Shuttle  program. 
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ACRONYMS  AND  ABBREVIATIONS 


A/C 

aircraft 

AFSCF 

Air  Force  Satellite  Control  Facility 

ALT 

Approach  Landing  Test 

ATP 

Acceptance  Test  Procedure 

CGW 

caution  and  warning 

CAPCOM 

spacecraft  communicator 

CC 

Command  Controller 

CCATS 

Command,  Communications,  and  Telemetry  System 

CCDS 

Command  and  Control  Data  System 

CCIUS 

Command  Controller- interim  upper  stage 

CDE 

Central  Data  Element 

CDR 

Critical  Design  Review 

C/O 

checkout 

COM 

Computer  Output  to  Microfilm 

CPU 

central  processing  unit 

CRT 

cathode  ray  tube 

CY 

calendar  year 

DAC 

digital -to-analog  converter 

D/CS 

Display/Control  System 

DOD 

Department  of  Defense 

ECS 

Environmental  Control  System 

EPS 

Electrical  Power  System 

ET 

external  tank 

EVA 

extravehicular  activity 

FA 

Flight  Analyst 

-a- 


FAIUS 

FBCS 

FC 


FD 

FEP 

FLT 

FOD 

FF 

FRR 

G5N 

GET 

GFE 

GMT 

GSFC 

ID 

I/O 

IUS 

IVA 

JSC 

KSC 

LED 

LOA 

LPS 

MBCS 

MCC 

MCCSS 

MCE 

MET 

MOD 


Flight  Analyst-interim  upper  stage 

fixed  base  crew  station 

flight  controller 

Flight  Director 

Front  End  Processor 

flight 

Flight  Operations  Director 
Flight  Planner 
Flight  Readiness  Review 
Guidance  and  Navigation 
ground  elapsed  time 
government  furnished  equipment 
Greenwich  mean  time 
Goddard  Space  Flight  Center 
Identification 
input/output 
interim  upper  stage 
intravehicular  activity 
Lyndon  B.  Johnson  Space  Center 
John  F.  Kennedy  Space  Center 
light  emitting  diode 
Landing  Operations  Area 
Launch  Processing  System 
Motion  base  crew  station 
Mission  Control  Center 

Mission  Control  Center  Simulation  System 
Mission  Control  Element 
mission  elapsed  time 
Mission  Operations  Directorate 


-b- 


0 


u 

0 


f 

MSC 

Manned  Spacecraft  Center 

i 
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1 . 2 PREFACE 


This  document  constitutes  an  annex  to  the  STS  Orbital  Requirements 
Document  (ORD)  and  covers  those  requirements  pertaining  to  the  in- 
terim upper  stage  (IUS).  The  document  defines  the  support  required 
of  the  Satellite  Control  Facility  (SCFJ  and  furnishes  the  SCF  with 
a basis  for  planning,  implementing  and  changing  hardware  and  soft- 
ware facilities  and/or  manpower  needed  to  support  the  STS. 

The  format  and  information  content  of  this  ORD  Annex  are  as  speci- 
fied in  SAMSO  Exhibit  61-98,  Revision  B. 


1.3  UPDATING  INSTRUCTIONS 


Revisions  to  this  document  will  be  issued  by  the  USAF  SAMSO  (LV-RO) 
as  required  to  reflect  changes  in  support  requirements  as  they 
occur.  It  is  not  intended  to  revise  the  document  on  a scheduled 
basis . 

When  revisions  are  required,  each  published  revision  will  contain 
the  following: 

• Title  page  with  approval  signature 

• Updated  instructions  page 

• Revised  summary  page 

• Revised  table  of  contents 

• Revised  pages 

Page  numbers  are  in  consecutive  order  within  each  subsection,  e.g. , 
2.1.1,  2.1.2,  2.1.3.  Additional  pages  required  due  to  a revision 
will  be  numbered  to  follow  the  previous  page  by  the  addition  of 
consecutive  decimal  digits,  e.g.,  2.1.1,  2. 1.1.1,  2. 1.1. 2.  Each 
revised  page  will  have  the  revision  number  and  date  of  issue. 
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1.4  REVISION  SUMMARY 
Description 
Original  Issue 


Date 

October  1974 
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1.10  DEFINITION  OF  ABBREVIATIONS 

CCU  Central  controller  unit 

CCLS  Computer  controlled  launch  set 

CEM  Co-elliptic  maneuver 

D/A  digital- to-analog 

DCU  Digital  computer  unit 

FTFD  Field  test  flight  director 

GSE  Ground  support  equipment 

IMG  Inertial  measurements  group 

IUS  Interim  upper  stage 

IRU  Inertial  reference  unit 

KSC  John  F.  Kennedy  Space  Center 

LPS  Launch  Processing  System 

ORD  Orbital  Requirements  Document 

PCM  Pulse  code  modulated 

PRN  Psuedo  random  noise 

PU  Propellent  utilization 

RC  Resistance-capacitor 

RCS  Reaction  control  system 

RF  Radio  frequency 

RMU  Remote  multiplexer  unit 

SCF  Satellite  Control  Facility 

SCU  Sequence  control  unit 

SEC  System  electronics  unit 

SGLS  Space  Ground  Link  Subsystem 

SIU  Servo  inverter  unit 

SMCC  Shuttle  Mission  Control  Center 

SPO  System  program  office 
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STC 

Satellite  Test 

Center 

TPF 

Terminal  phase 

final 

TPI 

Terminal  phase 

initiation 

TT5C 

Tracking,  Telemetry  and  Command 

VAFB 

Vandenberg  Air 

Force  Base 

VCO 

Voltage  controlled  oscillator 
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SECTION  2 


GENERAL  SYSTEMS  INFORMATION 


2.1  PROGRAM 

2.1.1  Program  Description.  The  STS  is  a new  USAF  program  which 
will  employ  the  Earth  Orbiting  Space  Shuttle,  a manned,  winged, 
reuseable  spacecraft,  as  well  as  several  configurations  of  upper 
stage  vehicles,  for  the  overall  purposes  of  deploying,  servicing, 
retrieving,  and  returning  to  earth  with  DOD  satellites.  This  doc- 
ument addresses  the  on-orbit  requirements  in  support  of  interim 
upper  stage  vehicles  to  be  utilized  by  the  DOD  during  initial 
phase  of  the  STS  program;  a separate  ORD  has  been  prepared  for 
the  Earth  Orbiting  Shuttle. 

The  upper  stage  vehicles  to  be  utilized  by  DOD  may  be  divided  into 
two  broad  categories,  as  follows: 

A.  Early  flights  of  the  Shuttle  will  utilize  an  interim  upper 
stage  ( I US)  for  the  sole  purpose  of  transporting  and  de- 
ploying one  or  more  satellites  from  a low  earth  orbit  (100- 
400  nmi  altitude)  to  a higher  altitude  not  attainable  by 

the  Shuttle.  Many  DOD  missions  are  concerned  with  the  place- 
ment of  satellites  in  synchronous  and/or  near-synchronous 
orbits  (altitude  approximately  19400  nmi) . At  the  release 
date  of  this  ORD  the  IUS  vehicles  have  not  be  definitized- 

B.  Later  flights  of  the  Shuttle  will  utilize  a more  sophisti- 
cated upper  stage,  designated  as  the  Tug.  The  Tug  will 
differ  from  the  IUS  in  two  important  ways,  namely: 

1.  The  Tug  is  substantially  larger  than  any  IUS  vehicle 
mentioned  above;  consequently,  the  Tug  can  transport 
heavier  satellites,  or  it  can  return  with  certain  DOD 
satellites  from  synchronous  altitude  to  a low  earth 
orbit,  such  as  to  permit  retrieval  of  the  mated  pair  by 
the  Shuttle. 

2.  The  Tug  will  possess  the  capability  to  rendezvous  with, 
and  dock  with,  satellites  in  orbits  above  those  achiev- 
able by  the  Shuttle,  followed  by  return  to  the  low 
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Shuttle  orbit.  By  contrast,  the  IUS  vehicles  will 
not  possess  the  rendezvous/docking  capability. 

DOD  flights  will  originate  either  at  KSC  or  at  Vandenberg  Air 
Force  Base  (VAFB) . Only  those  originating  at  KSC  will  utilize 
the  IUS;  later  flights  from  VAFB  may  employe  the  Tug,  but  retire- 
ments for  such  flights  are  not  yet  defined. 

When  the  vehicle  for  use  as  an  IUS  is  determined,  it  may  be  pro- 
vided systems  that  would  permit  its  recovery  for  reuse.  For 
purposes  of  this  document,  such  an  IUS  is  considered  to  be  a 
recoverable  IUS.  The  IUS  may  not  have  this  capability;  even  with 
this  capability,  the  IUS  may  not,  on  certain  missions  involving 
heavy  satellites  and/or  a high  deployment  altitude,  possess  the 
energy  capability  to  return  to  the  Orbiter  following  satellite 
deployment.  In  either  of  these  cases,  for  the  purpose  of  this 
document,  such  an  IUS  is  considered  to  be  an  expendable  IUS. 

in  the  event  of  certain  anomalous  behavior  of  the  IUS  and/or  its 
mated  satellite  load,  it  may  be  both  possible  and  desirable  for 
the  IUS  to  return  to  a Shuttle-retrieval  position  rather  than  de- 
ploying the  satell ite (s)  ; in  this  case  an  IUS  planned  to  be  expend- 
able may  suddenly  become  reuseable.  Also,  in  this  case  ground 
support  will  become  both  time  and  technically  critical.  However, 
it  is  emphasized  that  the  IUS  cannot  rendezvous  and  dock  with  a 
satellite;  if  the  IUS  is  to  return  a failed  satellite  to  the  Shut- 
tle rather  than  executing  a deployment,  appropriate  commands  must 
be  transmitted  from  the  ground  before  the  deployment  is  scheduled 
to  occur  and  while  the  IUS  still  possesses  sufficient  propellents. 

During  a normal  flight  an  expendable  IUS  will  be  preprogrammed  to 
perform  its  intended  functions.  In  these  flights  support  from  the 
ground  will  be  limited  to  tracking  and  monitoring,  and  support  from 
the  Shuttle  will  be  limited  to  possible  final  state  vector  update 
and  initiation  of  the  IUS  sequences. 

When  a reuseable  IUS  is  in  flight,  most  IUS  inctions  will  be  pre- 
programmed into  the  vehicle,  but  additional  .pate  data  may  be  re- 
quired by  the  IUS,  from  the  ground,  for  the  return  to  the  Shuttle. 


2.1.2  Mission  Support.  The  AFSCF  will  be  required  to  support  IUS 
orbital  operations  during  liftoff,  ascent,  and  all  on-orbit  phases 
of  those  DOD-STS  flights  utilizing  an  IUS.  Details  of  the  AFSCF 
support  requirements  are  provided  in  Section  4 of  this  annex.  The 
overall  control  support  of  each  IUS  is  dictated  by  the  following 
top-level  mission  requirements: 

A.  Obtain  tracking  data  for  ephemeris  determination. 

B.  Provide  command  generation. 

C.  Transmit  commands  on  a secure  uplink,  as  required  on  an  op- 
erational basis. 

D.  Receive  telemetry  data  on  a secure  downlink;  display  and 
distribute  data. 

E.  Provide  for  distribution,  storage  and  retrieval  of  vehicle 
history  data,  which  serves  as  the  basis  for  remedial  action 
in  the  event  of  anomalous  behavior. 
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2.3  LAUNCH  SCHEDULES 


IUS  launch  schedules  are  contained  in  Table  2.3-1. 


2.4  FUNCTIONAL  DESCRIPTION 

2.4.1  General . The  IUS  will  be  launched  while  stowed  within  the 
cargo  bay  of  the  Shuttle;  DOD  program  requirements  call  for  launches 
with  the  IUS  only  from  KSC.  Launch  windows  vary  from  one  mission 

to  the  next  and  will  be  provided  as  part  of  the  overall  mission 
planning  for  particular  missions.  During  the  1980-1991  period  DOD 
is  scheduled  to  fly  76  missions  from  KSC.  Early  flights  will  uti- 
lize the  IUS,  and  later  flights  will  utilize  the  Tug  as  an  optional 
upper  stage. 

2.4.2  Launch  and  Ascent.  Following  launch  the  Shuttle,  with  its 
stowed  IUS  and  attached  satellite (s) , will  be  injected  into  an 
elliptical  parking  orbit.  Perigee  and  apogee  altitudes  and  the 
orbital  inclination  are  mission-peculiar.  As  a general  rule,  the 
Shuttle  will  orbit  at  about  100-130  nmi,  although  certain  missions 
call  for  an  apogee  up  to  about  400  nmi. 

2.4.3  Payload  Deployment.  Following  insertion  of  the  Shuttle  into 
its  parking  orbit,  the  Shuttle  cargo  bay  doors  will  open  and  the 
IUS,  with  its  attached  satellite (s) , will  be  deployed.  Separation 
of  this  payload  combination  is  designed  for  a nominal  (TBD)  fps  and 
tipoff  angular  rate  of  less  than  (TBD)  deg/sec.  The  IUS  will  then 
be  reoriented  so  that  its  roll  axis  lies  along  the  velocity  vector 
and  the  IUS  altitude  control  system  (ACS)  will  be  activated. 

2.4.4  Payload  Postdeployment  Events.  Following  deployment  of  the 
payload,  the  Shuttle  crew  will  ensure  that  the  payload  orbit  is 
stable.  The  Shuttle  will  then  move  to  a safe  distance  (up  to  30 
nmi)  from  the  IUS.  By  radio  command  from  the  Shuttle, via  a Space 
Ground  Link  Subsystem  (SGLS)  RF  link,  the  IUS  sequencer  will  be 
initiated.  The  IUS  propulsion  system  will  then  fire  in  order  to 
place  the  IU3  in  a transfer  orbit. 

2.4.5  IUS  Transfer  and  Deployment  - Expendable  IUS.  The  IUS  en- 
gine burns  following  deployment  from  the  Shuttle  are  intended  to 
produce  a transfer  orbit  which  will  attain  the  required  apogee  for 
the  satellite (s) . The  IUS  is  preprogrammed  to  perform  all  guidance 
and  navigation  functions  for  this  transfer.  At  near  apogee  the 
orbit  plane  will  be  finalized  (plane  change)  and  the  orbit  circu- 
larized. For  approximately  75  percent  of  the  DOD  flights  from  KSC, 
the  intended  satellite  orbit  is  synchronous-equatorial. 

Just  prior  to  satellite  deployment  the  IUS  will  provide  an  arm  and 
fire  signal  to  separate  the  satellite.  Subsequent  to  separation 
the  IUS  will  be  reoriented,  and  fired  into  a non- interfering  orbit 
until  propellent  exhaustion. 
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2.4.6  Post-Satellite  Deployment.  Full  activation  procedures  for 
DOD  satellites  are  mission-peculiar;  typical  events  may  include: 

A.  Uncaging  of  a despin  platform 

B.  Release  of  tracking,  telemetry  and  command  (TT§C)  antennas 

C.  Unfurling  of  solar  panels 

D.  Satellite  spinup  (if  and  as  required) 

E.  Activation  of  communications  subsystem  (this  event  will  occur 
immediately  following  release  from  the  Shuttle  in  some  mis- 
sions) 

F.  Drift  to  final  position 

G.  Satellite  attitude  alignment 

Command,  checkout,  and  control  of  the  satellite  will  be  accomplished 
by  the  AFSCF. 
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2.5  INTERIM  UPPER  STAGE  SYSTEMS 

2.5.1  Functional  Relationship  Between  Subsystems.  Subsystems 
include: 

• Controls 

• Propulsion 

• Guidance 

• Communication 

• Navigation 

• Electrical  Power 

• Electrical  Distribution 

• Structures 

• Thermal  Control 

The  system  mission  is  primarily  accomplished  with  support  from  the 
subsystems  as  follows: 

• Satellite  stabilization,  station  keeping  and  antenna  point- 
ing - Controls  and  Propulsion  Subsystems. 

• Ground  control  for  command  of  functions  or  adjustments  - 
Communications  and  Controls  Subsystems. 

• Primary  Electrical  Power  - Electrical  Power  Subsystem. 

• Secondary  Electrical  Power  - Electrical  Distribution  Subsys- 
tem. 

• Status  and  performance  monitoring  - Communications  and  Elec- 
trical Distribution  Subsystem. 

• Spacecraft  guidance  - Guidance  Subsystem. 

• Spacecraft  navigation  - Navigation  Subsystem. 

Spacecraft  command  and  control  is  implemented  primarily  through 
onboard  stored-program  commands  of  the  individual  spacecraft 


2.5.1 


functions.  Automatic  onboard  control  logic  is  also  incorporated 
into  the  Electrical  Distribution  Subsystem  for: 

• Spacecraft  turn-on  and  deployment  subsequent  to  separation. 

• Switching  of  the  Communications  Subsystem  from  standby  to 
the  operational  mode  during  the  command  process. 

2.5.2  Description  of  Subsystems.  TBD 
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MISSION  SEQUENCE  OF  EVENTS 


2.6.1  General . This  section  oatlines  the  IUS  mission  events  for 
high-altitude  deployment  missions  when  the  IUS  will  be  recoverable 
by  the  Shuttle.  Mission  events  for  an  expendable  IUS  are  suffi- 
ciently similar  as  to  not  requre  elaboration. 

2.6.2  Geosynchronous  Deployment  Mission 

2.6. 2.1  Mission  Description.  This  mission  is  representative  of 
the  deployment  of  a payload  into  a geosynchronous  orbit.  The  Or- 
biter, IUS,  and  satellite  are  launched  due  east  from  KSC  and  ascend 
into  a 50  x 100  nmi,  28.5  degrees  parking  orbit.  The  IUS/satellite 
separates  from  the  Orbiter  and  performs  the  necessary  phasing, 
transfer  and  plane  change  maneuvers  to  place  the  satellite  at  the 
desired  longitude  location  in  the  synchronous  orbit.  After  satel- 
lite deployment,  the  IUS  returns  to  an  orbit  15  nmi  above  the  Or- 
biter parking  orbit.  After  IUS  retrieval,  the  Orbiter  waits  in 
parking  orbit  (115  nmi)  for  phasing  and  return  to  KSC. 

The  IUS/satellite  payload  will  be  under  Orbiter  hardwire  monitor 
from  liftoff  through  parking  orbit  deployment.  Predeployment  check- 
out of  the  IUS  and  the  satellite  will  consist  of  a hardwire,  mini- 
mal functional  check.  After  deployment,  initialization  and 
separation,  an  RF  check  will  be  performed  by  the  Orbiter  to  verify 
the  command  and  control  functions.  During  rendezvous,  the  Orbiter 
will  again  perform  an  RF  checkout  of  the  IUS  and  condition  it  for 
retrieval . 

2.6. 2. 2 Orbital  Timelines.  Two  orbital  timelines  are  included  in 
this  mission  description.  Figure  2.6-1  is  a timeline  for  the  en- 
tire flight  phase.  Figure  2.6-2  shows  the  IUS  timeline  for  the 
deployment  mission.  Major  events  are  identified  on  both  timelines. 

2. 6. 2. 3 Mission  Sequence.  The  mission  sequence  is  given  in 
table  2.6-1  and  is  intended  for  use  with  figure  2.6-1.  Times 
indicated  are  representative.  This  mission  sequence  includes 
representative  orbit  parameters. 
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Figure  2.6-1  Orbital  Activities  for  Geosynchronous  Mission 


Figure  2.6-2  IUS  Deployment  of  Satellite 


2. 6. 2. 4 Flight  Operations.  Because  of  its  complexity  this  mission 
has,  for  presentation  purposes,  been  separated  into  four  on-orbit 
segments.  The  segments  are  as  follows: 

• IUS  outbound  transfer  orbit  phase 

• IUS  return  transfer  orbit  phase 

• Orbiter/IUS  rendezvous 

• Retrieval  by  the  Shuttle 

Each  segment  is  graphically  described  in  figures  2.6-3  through 
2.6-6.  For  the  most  part,  the  figures  are  self  explanatory.  The 
following  paragraphs  briefly  address  each  segment  in  more  detail. 

2. 6. 2. 5 IUS  Outbound  Transfer  Orbit.  As  shown  in  figure  2.6-3, 
checkout  of  the  lUS/satellite  combination  begins  at  approximately 
1:36:00  ground  elasped  time  (GET)  and  is  complete  by  08:36:15  GET. 
At  completion  of  the  deployment,  the  IUS  outbound  transfer  orbit 
phase  begins  (figure  2.6-3). 

Depending  upon  the  placement  location  for  the  satellite,  the  IUS 
can  begin  a direct  transfer  from  the  Orbiter  parking  orbit  or  can 
execute  one  or  more  phasing  orbit  revolutions  to  place  the  IUS  in 
a more  favorable  transfer  burn  position  (the  more  complex  phasing 
orbit  maneuver  sequence  is  used  to  illustrate  the  transfer  burn 
sequence).  In  the  orbit  shown  (figure  2.6-3)  it  is  essential  that 
the  IUS  place  the  satellite  at  a specific  location  in  geosynchro- 
nous equatorial  orbit,  requiring  plane  changes  from  the  28.5  degree 
inclination  of  the  parking  orbit  and  two  phasing  orbit  revolutions 
to  place  the  IUS  in  the  required  position  for  the  transfer  orbit. 

As  shown  on  the  mission  sequence,  table  2.6-1,  it  is  mandatory  for 
the  IUS  to  execute  the  phasing  orbit  burn  at  the  seventh  descending 
node.  The  burn  is  executed  at  09:18:05  GET  and  places  the  IUS  in 
a 133  x 3611  nmi/27.9  degrees  elliptical  orbit.  Two  revolutions 
in  this  orbit  place  the  IUS  in  the  proper  position  for  the  trans- 
fer burn,  such  that  the  IUS  arrives  at  synchronous  orbit  at  the 
desired  location  and  inclination.  Provision  is  made  for  an  orbit 
trim  during  the  phasing  orbit  to  adjust  the  IUS  attitude  for  the 
transfer  orbit  burn  from  76.0  degree  inclination. 


TABLE  2.6-1 
MISSION  SEQUENCE 


MISSION 

EVENT 

TIME 

(GET) 

1 

LIFTOFF  - ORBITER  TARGETED  FOR  50/100  nml/ 
28.5° 

00:00:00 

2 

SRB  STAGING 

00:01:53 

3 

MECO 

00:08:19 

4 

PARK  ORBIT  INSERT  - 50.21/103.5  nmi/28.50 

00:08:19  j 

5 

APOGEE  ADJUST  - 98/104  nmi/28.490 

00:51:01 

6 

CIRCULARIZATION  - 134/134  nmi/28.490 

01 : 36 : 1 7 

7 

IUS  CHECKOUT  - (C/0  COMP  HALF  ORBIT  PRIOR 
TO  7TH  DESCENDING  NODE.  TARGETED  TO  SYNC 
ORBITER  POSITION) 

01  : 36 : 1 7 

8 

IUS  DEPLOY 

07:36:15 

9 

ORBITER  SEPARATE  - 131/148  nmi 

08:36:15 

10 

IUS  PHASING  BURN  - 7TH  DESCENDING  NODE 
133/3611  nmi 

09:18:05 

11 

ORBITER  CIRCULARIZE  - 138/138  (BEGIN  33 
REVOLUTIONS 

10:50:48 

12 

IUS  PHASING  REVOLUTIONS  (2) 

13 

IUS  TRANSFER  BURN  - 133/19,394  nmi/25.0° 

14:41:57 

14 

IUS  ORBIT  TRIM 

*17:35:00 

l 15 

IUS  CIRCULARIZATION  - 19,300/19,296  nmi 

19:57:26 

16 

IUS  ORBIT  ADJUST  (SYNC  ORBIT) 

AS  REQ'D 

17 

IUS  SATELLITE  DEPLOY 

* 31 :09:00 

18 

IUS  TRANSFER  BURN  - 164/19,323  (SYNC) 
2 .12° 

43:04:05 

19 

IUS  ORBIT  TRIM 

» 46 : 06 : 00 

20 

IUS  PHASING  BURN  - 164/3439  nmi/27.240 

48:21 : 23 

21 

IUS  ORBIT  TRIM 

*50:00:00 

; 22 

IUS  CIRCULARIZATION  - 165/161  nmi/28.52° 

51  :00 :08 

23 

ORBITER  RCC  BURN  - 128/162  nmi/25.51° 

51:55:07 

| 24 

ORBITER  EEM  BURN  - 162/128  nmi/28.50° 

52:43:06 

25 

ORBITER  TP I BURN  - 145/169  nmi/28.510 

53:06:58 

26 

ORBITER  TPF  - 154/168  nmi/28.490 

53:42:58 

27 

IUS  RETRIEVAL  (START) 

w 53 : 42 : 00 
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TABLE  2.6-1  (CONT'D) 


MISSION 

EVENT 

mrnm 

28 

EIGHT  REVOLUTIONS 

29 

DEORBIT  BURN  - 10/161  nmi/28.480 

69:25:06 

30 

LANDING 

70:26:01 

2 REVS 


IUS  EVENTS  PHASING  BURN  THROUGH  OUTBOUND  CIRCULARIZATION 


11 

PHASING  BURN 

09:18:05 

133/3611  NMI 

27.19 

12 

13 

ORBIT  TRIM 
TRANSFER  BURN 

14:41:57 

133/19300 

26.0° 

14 

15 

ORBIT  TRIM 
CIRCULARIZE 

19:57:26 

19300/19297 

0.0° 

ORBITER  NOT  SHOWN 

CONTINUES  IN  PARK  ORBIT  UNTIL  IUS  RETURN  (33  REVS) 
138/138  NM  28.52° 
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Figure  2.6-3  IUS  Outbound  Transfer  Orbit  Phase 
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At  14:41:57  GET  the  IUS  executes  the  transfer  burn  at  the  perigee 
of  the  phasing  orbit  (133.0  nmi/26.0°).  An  orbit  trim  is  executed 
during  the  transfer  orbit  ascent  to  adjust  IUS  attitude  for  the 
circularization  burn  and  plane  change.  Transfer  orbit  plane  and 
circular  orbit  plane  coincide  at  19,400  nmi  and  the  IUS  executes 
a circularization/plane  change  burn  into  a 19,400  * 19,400  nmi/0.0 
degree  orbit.  Any  necessary  orbit  adjustment  is  accomplished  by  the 
IUS  and  the  satellite  is  deployed.  Initiation  may  be  by  the  IUS 
separation  function  or  by  ground  command.  Complete  operational 
checkout  of  the  satellite  is  the  responsibility  of  the  AFSCF  ground 
system.  Moreover,  a predeployment  check  may  be  made  to  determine 
basic  command  and  control  capability,  such  that  if  the  checkout  is 
negative,  the  satellite  can  be  returned  by  and  with  the  IUS.  The 
complete  operational  check,  including  sensor  stimulus/response, 
can  be  made  only  after  separation  and  initialization. 

2.6. 2.6  IUS  Inbound  Transfer  Orbit.  As  stated  previously,  this 
representative  mission  has  been  made  complex  for  illustrative  pur- 
poses and  severe  time  constraints  have  been  placed  on  orbit  maneu- 
vers to  indicate  requirements;  in  this  case,  the  IUS  phasing  orbits 
to  adjust  to  specific  deployment  requirements. 

If  it  were  not  for  the  time  constraint  imposed  by  the  IUS  de-orbit 
time,  a simple  direct  transfer  orbit  to  the  Orbiter  parking  orbit 
could  be  made  at  any  time.  Assuming,  howover,  that  total  on-orbit 
time  should  be  minimized,  the  IUS  phasing  orbit  har  been  selected 
so  that  the  IUS  can  be  placed  within  90  nmi  of  the  Orbiter  --  thus 
minimizing  rendezvous  and  retrieval  time.  The  inbound  transfer 
orbit  is  illustrated  in  figure  2.6-4. 

At  43:04:05  GET,  the  IUS  executes  a de-orbit  transfer  burn  into  a 
164  x 19,323  nmi/26.12  degree  elliptical  orbit.  The  inbound  de- 
scent requires  approximately  5 hours,  during  which  an  orbit  trim 
maneuver  may  be  required  to  adjust  the  IUS  attitude  for  the  phasing 
burn.  At  48:21:23  GET,  the  phasing  orbit  burn  is  executed  at  the 
transfer  orbit  perigee  (164  nmi),  placing  the  IUS  in  a 164  x 3439 
nmi/27.24  degree  phasing  orbit.  After  one  orbit,  the  IUS  executes 
a circularization  burn  at  the  perigee  of  the  phasing  orbit,  result- 
ing in  a 165  x 165  nmi/28.52  degree  circular  orbit,  above  the  Or- 
biter parking  orbit. 

As  shown  in  the  mission  sequence,  table  2.6-1,  the  Orbiter  is  com- 
pleting the  thirty-third  revolution  in  a 134  x 134  nmi/28.5  degree 
orbit  and  is  within  tracking  sensor  range  of  the  IUS  (behind  and 
below) . 
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IUS  EVENTS  POST-DEPLOV  (RETRIEVAL) 


18 

19 

TRANSFER  BURN 
ORBIT  TRIM 

43:04:05 

164/19323 

26.12 

20 

21 

PHASING  BURN 
ORBIT  TRIM 

48:21:23 

164/3439 

27.24 

22 

CIRCULARIZATION 

51:00:08 

161/165 

28.52 
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Figure  2.6-4  IUS  Return  Transfer  Orbit  Phase 
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IUS  circularization  into  the  rendezvous  orbit  completes  the  IUS 
inbound  transfer  orbit  phase. 

2. 6. 2. 7 IUS/Orbiter  Rendezvous.  The  Orbiter  is  capable  of  at 
least  two  types  of  rendezvous  sequences:  direct  ascent  and  multi- 

revolution, co-elliptic.  Direct  ascent  rendezvous  must  be 
controlled  onboard  the  Orbiter  because  network  support  is  not 
available  on  a continuous  basis.  Figure  2.6-5  illustrates  the 
rendezvous  sequence. 

Trajectory  calculation  for  the  co-elliptic  sequence  must  be  accom- 
plished both  onboard  the  Orbiter  and  by  the  AFSCF  ground  system. 

The  Orbiter  crew  must  be  able  to  analyze  the  effect  of  any  correc- 
tion burn  on  the  altitude,  phasing,  and  time  of  rendezvous,  while 
the  ground  system  processes  the  same  information  to  determine 
station  contact  parameters.  The  Orbiter  assumes  prime  responsi- 
bility as  soon  as  its  sensors  acquire  the  target. 

It  is  illustrated  in  figure  2.6-5  that  the  IUS  returns  to  an  orbit 
co-elliptical  to  the  Orbiter  parking  orbit  somewhat  higher  than 
the  parking  orbit  altitude.  The  specific  orbits,  shown  on  the  mis- 
sion sequence,  table  2.6-1,  are  134  * 134  nmi  for  the  Orbiter  cir- 
cular parking  orbit  and  165  x 161  nmi  for  the  IUS  co-elliptic 
orbit. 

Rendezvous  between  the  Orbiter  and  the  returning  IUS  begins  fol- 
lowing the  IUS  circularization  burn.  As  stated,  IUS  circulariza- 
tion is  at  the  perigee  of  the  inbound  transfer  orbit  or  (as  in  this 
case)  the  phasing  orbit.  The  phasing  orbit  places  the  rendezvous 
target  within  minimum  maneuver  range  of  the  Orbiter.  The  Orbiter 
immediately  begins  rendezvous  sensor  acquisition.  Fifty-four  min- 
utes later,  the  Orbiter  initiates  a sequence  of  maneuvers  resulting 
in  rendezvous  2.7  hours  after  the  IUS  circularization  burn.  The 
Orbiter  executes  a rendezvous  corrective  combination  (RCC)  burn  and 
a co-elliptic  maneuver  (CEM)  burn  to  bring  it  in  place  for  the  ter- 
minal phase  initiation  (TPI)  and  terminal  phase  final  (TPF) . Due 
to  their  small  magnitude,  the  TPI  and  TPF  maneuvers  are  performed 
using  only  the  reaction  control  system  (RCS) . 

The  RCC  burn  is  intended  to  place  the  IUS  orbit  10  nmi  above  that 
of  the  Orbiter  and  to  establish  a proper  phase  angle  (about  -1.1 
degree)  at  the  CEM  point.  Residual  out-of-plane  error  would  be 
corrected  by  this  maneuver.  The  CEM  maneuver  circularizes  the  or- 
bit and  nulls  the  residual  out-of-plane  velocity  between  the  two 
vehicles.  Except  for  attitude  control,  the  IUS  becomes  passive- 
cooperative  for  the  final  phase  of  the  mission;  the  Orbiter  becomes 
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Figure  2.6-5  IUS/Orbiter  Rendezvous 
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the  active  vehicle.  After  the  CEM,  the  phase  angle  between  the 
Orbiter  and  the  IUS  is  about  1.1  degrees  and  the  Orbiter  reduces 
this  range  from  the  IUS  at  a near-constant  rate.  Approximately 
45  minutes  later,  the  Orbiter  reaches  the  TF'I  point,  and  the  final 
approach  phase  of  the  rendezvous  is  initiated  (53:06:58  GET)  on 
the  mission  sequence. 

2.6. 2.8  Retrieval  of  the  IUS.  Retrieval  operations  (illustrated 
in  figure  2.6-6)  begin  at  approximately  53:43:00  GET  and  consist 
of  the  jettison  of  any  remaining  IUS  fuel,  safing  functions,  suf- 
ficient commands  to  correct  the  IUS  attitude  for  retrieval,  and 
deactivation  of  the  IUS  reaction  control  system  (attitude  control). 

Grapple,  retract,  and  securing  of  the  IUS  in  the  payload  bay  re- 
quire no  more  than  20  minutes  and  include  remating  of  the  IUS 
umbilicals  in  the  payload  bay,  primarily  for  safety  purposes.  The 
spacecraft  then  prepares  for  reentry  and  landing  at  KSC. 
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IUS  /ORBITER  EVENTS  - RETRIEVAL  , DEORBIT  , & LANDING 
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Figure  2.6-6  Retrieval  Phase  (Also  Illustrates  Landing) 


2.6.13 


2.7  GROUND  SUPPORT  FUNCTIONS 


The  AFSCF  will  conduct  the  orbital  operations  required  to  support 
each  IUS  deployment  mission.  The  operations  support  will  include: 

• Vehicle  tracking  of  the  mated  IUS/satellite  preceding  satel- 
lite release. 

• Vehicle  tracking  of  the  separated  vehicles 

• Telemetry  data  receiving,  recording,  processing,  and  distri- 
bution 

• IUS  command  generation,  transmission,  and  verification 

• Satellite  commanding,  control,  and  housekeeping 

This  support  will  be  provided  by  remote  tracking  stations,  as  visi- 
bility to  the  vehicles  permits,  dependent  upon  mission  requirements, 
elapsed  time,  and  station  location.  Specific  support  requirements 
are  mission  peculiar. 

Station  scheduling  and  configuration  direction  in  support  of  IUS 
flights  will  be  provided  by  the  Satellite  Test  Center  (STC) . 

Support  requirements  include  the  use  of  the  station  SGLS  pseudo- 
random noise  (PRN)  signals  for  range  and  carrier  doppler  shift 
(range  - rate)  , and  the  optional  use  of  the  COMSEC  ground  equip- 
ment for  encryption  of  transmitted  commands  and  decryption  of  re- 
ceived telemetry.  The  STC  will  support  maneuver  command  operations 
using  ephemeris  data  supplied  by  a (TBD)  orbit  ephemeris  system  and 
telemetry  inputs  supplied  from  the  IUS  and  from  the  deployed  satel- 
lite (s) . 
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2.8  SCF  SUPPORT  WORKLOAD 

Tracking  support  of  the  mated  IUS/satellite(s)  will  be  required 
during  the  orbital  transfer  to  high  altitude  to  correct  possible 
IUS  injection  errors  and  to  provide  the  satellite  position  accuracy 
required  to  station  the  satellite(s)  at  the  intended  location(s). 
Tracking  support  is  also  required  for  the  deployed  satellite (s)  and 
for  the  return-to-Shuttle  phase  for  a reuseable  IUS. 

Telemetry  support  will  be  required  during  these  periods  to  deter- 
mine the  status  of  vehicle  subsystems  and  to  determine  if  attitude 
correction  maneuvers,  or  any  other  remedial  action,  are  required. 

Tracking  and  telemetry  support  requirements  will  be  mission- 
peculiar  and  will  include  those  tracking  stations  which  have  a 
clear  line  of  sight  to  the  IUS  and  satellite(s)  on  a scheduled 
basis.  It  is  estimated  that  minimum  support  requirements  will  be 
as  follows: 

A.  Support  for  up  to  (TBD)  minutes  as  soon  after  deployment 
from  the  Shuttle  as  a line-of-sight  permits. 

B.  Support  for  at  least  (TBD)  minutes  approximately  halfway 
through  the  orbital  transfer  coast. 

C.  Support  commencing  approximately  (TBD)  minutes  prior  to  de- 
ployment of  any  satellite  from  the  IUS,  and  continuing 
through  deployment,  satellite  checkout,  commencement  of 
satellite  operations,  and  either  the  initiation  of  the  (re- 
useable) IUS  return  orbital  transfer  or  the  depletion  burn 
of  an  expendable  IUS. 

D.  Support  of  a reuseable  IUS  for  a minimum  of  (TBD)  minutes 
approximately  halfway  through  the  orbital  transfer  coast  of 
a reuseable  IUS. 

E.  Support  contact  for  up  to  (TBD)  minutes  with  the  Shuttle, 
following  retrieval  of  a recoverable  IUS,  as  line-of-sight 
permits . 
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SECTION  3 


IUS  FLIGHT  ELEMENT  CHARACTERISTICS 

3.1  IUS  VEHICLE  PARAMETERS 
TBD 
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3.2  IUS  TRAJECTORIES 


Each  mission  utilizing  the  IUS  dictates  a unique  set  of  trajectory 
parameters  which  are  defined  in  the  mission  annexes.  The  IUS  pro- 
gresses through  a series  of  mission  dependent  flight  phases.  The 
flight  phases  include  the  following: 

• Ascent  to  satellite  ejection  orbit 

• Insertion  into  satellite  ejection  orbit 

• Satellite  ejection  orbit 

• Satellite  ejection 

• Descent  to  IUS/Orbiter  rendezvous  orbit 

• Rendezvous  orbit 

Each  flight  has  an  attendent  set  of  trajectory  parameters.  The 
trajectory  parameters  (depending  upon  flight  phase)  include  the 
following: 

• Altitude  or  apogee  radius,  perigee  radius  and  arguments 
thereto 

• Period 

• Longitude 

• Latitude 

• Ascending  node 

• Descending  node 

• Inclination  angle 

Figures  2.6-3  through  2.6-6  of  this  annex  depict  the  on-orbit  phases 
of  a representative  recoverable  IUS  flight  profile,  beginning  with 
deployment  from  the  Orbiter  and  terminating  with  insertion  into 
rendezvous  orbit. 
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3.3  TRACKING 


3.3.1  Tracking  Aids 

3.3.1. 1 Orbital  Transfer  Phase.  Prior  to  separation  of  the  satel- 
lite^) from  the  IUS,  the  satellite  systems  capable  of  providing 
tracking  assistance  are  inactive.  During  this  period,  angles-only 
tracking  information  can  be  obtained  by  the  SCF  remote  tracking 
stations  utilizing  the  IUS  S-band  telemetry  RF  signal.  The  RF  car- 
rier frequencies  (i.e.,  SGLS  channel  selection)  for  the  IUS  and  its 
mated  satellite(s)  are  mission  peculiar  and  will  be  selected  prior 
to  individual  missions.  Any  of  the  20  standard  SGLS  channels  may 
be  used  for  the  IUS;  a separate  channel  (s)  will  be  used  for  com- 
munications to  the  satellite (s) . During  the  orbital  transfer, 
tracking  will  occur  only  between  the  IUS  and  one  or  more  SCF  ground 
stations . 

3.3. 1.2  Orbital  Phase.  Following  separation  of  the  IUS  and  its 
mated  payload  from  the  Orbiter,  the  SCF  remote  tracking  stations 
will  be  able  to  measure  the  following  parameters  via  the  SGLS  tele- 
metry system: 

• Range  through  time  shift  of  the  PRN  range  code 

• Range-rate  through  coherent  carrier  doppler  shift 

• Azimuth  r -«d  elevation  angle  based  on  the  apparent  angle  of 
arrival  or  the  RF  signal  transmitted  from  the  IUS. 

3.3.2  Active  Tracking  System 

3. 3. 2.1  PRN  Ranging.  Range  is  determined  by  measuring  the  time 
shift  (propagation  delay)  experienced  by  a pseudo- random  binary 
ranging  code  which  is  specifically  chosen  because  of  its  correla- 
tion characteristics.  This  code,  generated  in  the  transmitter 
coder,  phase-modulates  the  ground-to-satellite  carrrier,  as  shown 
in  figure  3.3-1. 

3. 3. 2. 2 Doppler  Frequency  Shift  Tracking.  Both  one-way  and  two- 
way  techniques  can  be  implemented  for  this  range  rate  tracking 
function.  In  the  two-way  technique,  a precise  determination  of 
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range-rate  is  made  possible  through  the  use  of  the  satellite  phase- 
locked  transponder  which  generates  a coherent  carrier  at  a rational 
fraction  (256/205)  of  the  received  frequency.  The  satellite  tran- 
sponder is  interrogated  by  the  ground  transmitter  operating  at  a 
frequency  of  205/256  times  the  base  frequency  (fr  x) . This  results 
in  a received  signal  at  the  satellite  of  205/256  (fr  x)  plus  one- 
way doppler  shift.  This  frequency  is  multiplied  by  256/205  in  the 
satellite  transponder  and  retransmitted  to  the  ground  where  it  is 
received  with  additional  one-way  doppler,  as  shown  in  figure  3.3-2. 
Precise  range-rate  data  is  extracted  through  appropriate  mixing  of 
the  filtered  received  signal  from  the  ground  receiver  with  signals 
from  the  ground  transmitter.  Phase-lock  techniques  are  also  utilized 
in  the  ground  receiver  to  provide  an  efficient  tracking  filter  for 
the  received  carrier.  This  technique  permits  near  optimal  demodula- 
tion of  the  telemetry  and  ranging  information  carried  by  this  signal. 

In  the  absence  of  an  uplink  signal,  one-way  doppler  tracking  is  pos- 
sible by  using  a stable  crystal  oscillator  in  place  of  the  voltage- 
controlled  oscillator  (VCO)  to  drive  the  satellite  transponder  trans- 
mitter. This  is  termed  the  "noncoherent"  operating  mode  for  the 
transponder. 

The  signal  is  subsequently  demodulated  in  the  satellite  command  re- 
ceiver, filtered,  and  used  to  remodulate  the  satellite-to-gromd 
carrier  without  further  processing.  This  carrier  is  processed  by 
the  ground  receiving  equipment  to  provide  a noise-corrupted,  delayed 
replica  of  the  original  transmitted  signal.  A local  model  of  the 
ranging  code  is  generated  in  the  receiver  coder  and,  by  a generated 
delay,  is  made  to  coincide  with  the  received  code  through  the  use 
of  cross-correlation  techniques.  The  measured  delay  with  respect 
to  the  transmitted  code  is  equal  to  the  round  trip  transit  time  and 
thus  measures  satellite  range.  Once  range  acquisition  has  been  ac- 
complished, the  data  may  be  continually  updated  using  internal  dop- 
pler signals. 

To  assure  an  unambiguous  measurement  of  the  satellite  range,  the 
code  period  must  be  greater  than  the  round  trip  propagation  time. 

Two  code  lengths  will  be  provided  for  the  SGLS ; this  permits  an 
unambiguous  range  determination  to  400,000  nmi  for  the  long  code 
and  5000  nmi  for  the  short  code.  The  ranging  codes  are  formed  by 
a synchronous  combination  of  four  binary  code  components  plus  a two- 
bit  clock  code.  To  further  reduce  the  time  required  for  acquistion, 
a short  code  is  provided  for  range  uncertainties  of  less  than  5000 
nmi . 


3.3.3 


Figure  3.3-2  Doppler  Shift  System  Block  Diagram 


3,3.3  Antenna  Gain  and  Isotropic  Antenna  Patterns.  The  IUS  will 
employ  right-hand  circularly  polarized  antenna  subsystem  for  re- 
ception of  uplink  commands,  ranging,  and  transmission  of  downlink 
telemetry.  It  is  a DOD  requirement  that  communications  to  the  IUS, 
from  a remote  tracking  station,  shall  be  possible  independent  of 
the  IUS  attitude.  The  onboard  antenna  subsystem  configuration  to 
meet  this  requirement  has  not  yet  been  defined;  correspondingly, 
the  antenna  subsystem  gain  and  radiation  pattern  is  TBD.  Operation 
shall  be  possible  on  any  of  the  20  standard  SGLS  channels. 


3.4  TELEMETRY  DOWNLINKS 


There  are  two  downlinks  in  the  IUS  for  medium  and  high-rate  tele- 
metry. The  medium  rate  telemetry  downlink  carrier  is  phase  coher- 
ent with  the  uplink  carrier  and  contains  a range  signal,  IUS  health 
and  status  data  and  command  authentication  of  verification  informa- 
tion. The  high  rate  telemetry  downlink  contains  satellite  data. 

3.4.1  RF  Configuration 

Characteristic  Requirement 

Frequency  range  2200-2300  MHz 

(20  standard  SGLC  carrier 
frequencies) 

Frequency  assignment  TBD  (mission  peculiar) 

Transmitter  power  output  TDB  (1.0  watt  typical) 

Transmission  loss  from  trans-  TBD 

mitter  to  antenna 


3.4.2  Modulation  Technique 

Characteristic  Requirement 

Medium  rate  TLM 


Subcarrier  Frequencies 

Subcarrier  Modulation 
1.024  MHz 
1.7  MHz 

Subcarrier  Frequency 

Tolerance 
1.024  MHz 
1.7  MHz 

Subcarrier  Frequency 

Stability 

Telemetry  PCM  Bit  Rate 
1.024  MHz 
1.7  MHz 


1.024  MHz  and  1.7  MHz 


PCM/PSK 

PCM/FM/FM 


±60  Hz 
+180K  Hz 

TBD 


7.8  b/s  to  128  kb/s 
125  b/s  to  256  kb/s 


3.4.1 


Characteristic 


Requirement 


Telemetry  bit  stability 

Telemetry  word  length 

Telemetry  frame  length 

PRN  modulation  technique  on 
to  carrier 

High  rate  TLM 

Subcarrier  Frequency 

Subcarrier  frequency 
stability 

Subcarrier  modulation 
technique 

Telemetry  data  rate 
Telemetry  bit  stability 
Telemetry  word/frame  length 


TBD 

TBD 

TBD 

PM 


5 MHz  below  medium  rate  TLM 
carrier  frequency 

TBD 

PCM/PSK/PM 

128  kb/s  to  1024  kb/s 

TBD 

TBD 


3.4.3  Word/Frame  Structure.  Digital  and  discrete  input  signals 
are  processed  into  a PCM  time-multiplexed  serial  bit  stream,  en- 
crypted, and  sent  to  transmitter  equipment. 

The  mainframe  and  subframe  word  structure  are  TBD. 


3.4.4  Encryption  Equipment.  The  IUS  may  contain  GFE  TBD  telemetry 
encryptors  to  accept  the  PCM  coded  telemetry  data  and  route  the 
secured  output  to  the  transmitter. 

3.4.5  Antenna  Gain  Characteristics.  The  IUS  antennas  shall  have 
TBD  gain  characteristics.  (See  paragraph  3.3.3). 


3.4.6  Telemetry  Downlink  Calculations 


Parameter 

IUS  transmitter  power 
IUS  line  losses 


Nominal  Value 

TBD  (1-watt  typical) 
TBD 


3.4.2 


Parameter 


Nominal  Value 


IUS  diplexer  losses 

TBD 

IUS  antenna  gain 

TBD 

Polarization  loss 

TBD 

Space  loss  at  TBD  nmi 

TBD 

Atmospheric  attenuation 

TBD 

Received  power  at  the  ground 
antenna 

*> 

TBD 

3.4.3 


3.5  IUS  UPLINK 


The  uplink  carrier  is  directly  phase-modulated  by  a composite  sig 
nal  consisting  of  the  PRN  ranging  signal  and  the  frequency-shift 
keyed  command  subcarrier  frequencies  representing  the  ternary  1. 

0 and  S command  data. 


3.5.1  RF  Configuration 

Characteristic 

Frequency  range  (assigned 
limits) 

Receiver  carrier  frequency 
assignment 

Receiver  noise  threshold 
S/N 

Receiver  frequency  accuracy 
Command  modulation  technique 

Command  rate 

Command  subcarrier  frequency 
assignments 

Composite  command  modulation 
loss  (modulation  index  « 0.3 
radian  for  both  commands  and 
PRN) 

PRN  ranging  data 

Composite  PRN  ranging  modula- 
tion loss  (modulation  index 
= 0.3  radian  for  both  com- 
mands and  PRN) 

Transmission  loss  from 
diplexer  to  either  receiver 


Requirement 

1750  to  1850  MHz 

(20  standard  SGLS  carrier 

frequencies) 

TBD  (mission  peculiar) 

TBD 

±0.002  percent 

Ternary  FSK,  amplitude  modu- 
lated with  clock  waveform 

1 or  2 Kilobaud , ±20  percent 

65  (S),  76  (0)  and  95  (1)  kHz 
±0.4  kHz 

14.0  dB 


NRZ-L  at  500  kb/s 
10.8  dB 


TBD 


3.5.2  Types  of  Commands.  TBD 


3.5.3 


Command  Tone  Demodulator/Decoder 


3. 5. 3.1  Signal  Reception  and  Initial  Processing.  TBD 

3. 5. 3. 2 PRN  Ranging.  The  PRN  uplink  modulation  is  detected  by  the 
phase-locked  spacecraft  receiver,  and  the  PRN  output  is  supplied  to 
the  dual  baseband  assembly  for  carrier  modulation  and  transmission 
back  to  the  ground  station  on  the  telemetry  downlink.  PRN  ranging 
is  available  in  the  coherent  mode  only.  The  coherent  mode  exists 
when  transmitter  No.  1 is  operating  with  receiver  No.  1 or  trans- 
mitter No.  2 is  operating  with  receiver  Nj.  2. 

3. 5. 3. 3 Command  Modulation.  The  command  carrier  modulation  con- 
sists of  three  subcarriers  turned  on  one  at  a time.  The  subcarrier 
frequencies,  listed  in  paragraph  3.5.1,  are  assigned  to  represent 
an  S,  0,  or  a 1.  A clock  signal  is  amplitude-modulated  on  the  sub- 
carrier signal.  The  subcarriers  are  individually  keyed  at  the 
ground  station  by  digital  information  transmitted  from  the  command 
generator  on  three  digital  lines.  Condition  S,  0,  or  1 is  trans- 
mitted by  turning  on  the  corresponding  subcarrier  fa,  f b , or  fc, 
one  subcarrier  at  a time,  in  FSK  fashion.  The  bit-synch  informa- 
tion (clock)  amplitude  modulates  the  keyed  subcarrier  with  a tri- 
angular wave  at  half  the  bit  rate  and  in  suitable  phase. 

3. 5. 3. 4 Signal  Conditioning.  TBD 

3. 5. 3. 5 Command  Decoding.  TBD 

3. 5. 3. 6 Command  Processing.  TBD 

3.5.4  Command  Word  Structure.  TBD 

3.5.5  Command  Verification.  TBD 

3.5.6  Command  Uplink  Calculation 

Parameter 

Ground  station  transmitter 
power:  10  kw  (dBm) 

Ground  station  line  losses 
transmitter  to  antenna  (dB) 


Nominal  Value 
+ 70.0 

-0.6 


3.5.2 


Parameter 


Nominal  Value 


Ground  station  antenna  gain  +46.0 

(60  ft.  dish  RHCP)  (dB) 

Ground  station  radome  loss  (dB)  -0.6 

Atmospheric  attenuation  (dB)  -TBD 

Polarization  losses  (dB)  -0.2 

Space  loss  at  TBD  nmi  (dB)  TBD 

IUS  receiver  antenna  gain  +TBD 

±X  deg  beamwidth  (dB) 

IUS  duplexer  losses  (dB)  -TBD 

IUS  line  losses  (dB)  -TBD 

Received  power  at  IUS  (dBm)  -TBD 


3.5.7  Antenna  Characteristics.  TBD. 


SECTION  4 


DETAILED  SUPPORT  REQUIREMENTS 


4.1  PAD  CHECK  REQUIREMENTS 

SFC  support  required  for  the  IUS  only  is  as  follows: 

• Mission  support  planning 

• Software  coordination 

• IUS/SCF  compatibility  tests 

• Coordination  of  data  base 

4.1.1  Mission  Support  Planning.  Planning  support  is  required  to 
coordinate  program  requirements  with  SCF  support  capability,  with 
emphasis  on  software  program  interface  capability  and  hardware. 

4.1.2  Software  Coordination.  Special  coordination  is  required 
between  contractors  and  KSC  to  ensure  compatibility  between  pre- 
launch command  and  telemetry  checkout  and  KSC  support/software 
capability.  Normal  coordination  activities  are  required  in  the 
preparation  of  telemetry  modes  for  data  display  which  are  compati- 
ble with  the  IUS  telemetry  format. 

4.1.3  IUS/SCF  Compatibility  Tests.  Tests  will  be  required  at  KSC 
to  verify  the  interface  compatibility  of  the  IUS  Tracking,  Tele- 
metry, and  Command  (TT§C)  Subsystem  (using  engineering  model  hard- 
ware) with  the  SCF/SGLS  hardware.  Magnetic  tapes  of  simulated  IUS 
telemetry  data  will  be  provided  by  the  contractor  to  verify  tele- 
metry modes  and  for  use  in  rehearsals. 

4.1.4  Coordination  of  Data  Base.  Data  base  tables  are  required  for 
the  communications  ground  terminals  which  will  support  the  Orbiter 
during  deployment,  mission  and  recovery  of  the  IUS  (when  applicable). 
The  information  required  in  the  tables  is  TBD. 


4.1.1 


4.2  COUNTDOWN  REQUIREMENTS 

There  are  no  IUS-peculiar  requirements  on  the  SCF  during  the  count- 
down. Upon  request  from  KSC,  during  the  countdown,  the  SCF  will  be 
required  to  report  its  readiness  status  via  voice  link  to  KSC. 


4.2.1 


4.3  ASCENT  REQUIREMENTS 


4.3.1  Definition.  The  ascent  phase  for  this  ORD  is  from  liftoff 
at  KSC  through  separation  of  boosters  and  external  tasks  and  in- 
jection of  the  Orbiter  into  orbit. 

4.3.2  Tracking  Requirements.  There  are  no  tracking  requirements 
peculiar  to  the  IUS  during  ascent* 

4.3.3  Communications . A voice  link  is  required  between  the  KSC 
and  the  Orbiter  during  ascent  for  backup  reporting  of  IUS  status. 


4.3.1 


4.4  ON-ORBIT  REQUIREMENTS 

ihc  SCF  is  required  to  provide  prime  support  to  IUS  orbital  opera- 
tions after  deployment  from  the  Orbiter.  The  support  required  is 
listed  in  three  general  categories:  maneuvers,  communications, 

and  IUS  operations. 

4.4.1  Maneuvers . During  deployment,  maneuver,  and  recovery  of  the 
IUS,  the  SCF  shall  provide  backup  positional  data  to  the  Orbiter  or 
guidance  update  directly  to  the  IUS.  These  updates,  as  well  as  IUS/ 
RTS  telemetry,  shall  be  via  standard  SGLS. 

4.4.2  Communications . SCF  communications  will  be  required  during 
TBD  portions  of  the  IUS  flight,  as  lines  of  sight  permit.  Detailed 
utilization  of  the  existing  net  is  TBD,  and  will  be  mission-peculiar. 

4.4.3  IUS  Operations.  Events  requiring  SCF  support  include  backup 
command  transmission,  vehicle  tracking,  data  reception,  display  and 
recording.  Specific  details  are  TBD  and  are  mission-peculiar. 


4.4.1 


4.5  TRACKING  REQUIREMENTS 


4.5.1  SCF  Tracking  Support.  Tracking  is  required  of  the  SCF  to 
meet  the  specified  time  and  accuracy  requirements  for  updating  of 
the  IUS  ephemeris,  to  support  station  handover,  command  positional 
update,  and  telemetry  reception.  Detailed  tracking  requirements 
are  TBD  and  are  mission-peculiar. 

4. 5.1.1  Station  Acquisition.  The  activities  which  will  be  sup- 
ported, and  the  timelines  for  groundtracking,  are  mission-peculiar. 
After  IUS  deployment,  tracking  is  required  for  the  determination 

of  the  orbit  parameters  and  the  prediction  of  on-station  arrival 
time.  During  and  after  deployment,  sufficient  tracking  time  per 
day  will  be  allotted  to  support  IUS  accuracy  requirements. 

4. 5. 1.2  Repositioning . Ephemeris  requirements  for  IUS  update  and 
maneuvering  are  TBD. 

4.5.2  IUS  Tracking  Planning.  The  operational  planning  of  IUS 
tracking  will  be  as  follows. 

4. 5. 2.1  Normal  Operation.  A schedule  of  normal  trajectory  and 
maneuvers  will  be  determined  in  advance  and  transmitted  to  the 
field  test  flight  director  (F'fFD) . The  ephemeris  will  be  deter- 
mined in  accordance  with  the  planned  operation  and  will  be  provided 
as  an  input  to  the  station  processor  for  generation  of  tracking 
slave  data  and  backup  commanding. 

4. 5. 2. 2 Contingency  Operation.  In  the  event  of  contingencies  in 
IUS  operation  SCF  support  is  TBD. 


4.5.1 


4.6  EPHEMERIS  ACCURACY  REQUIREMENTS 

4.6.1  IUS  Ephemeris.  The  accuracy  required  for  the  IUS  ephemeris 
will  vary  with  the  mission  phase  and  is  summarized  in  table  4.6-1. 


(1)  CORRESPOND  TO  DRIFT  RATE  ERROR,  WHICH  IS  EQUALLY  DIVIDED  OVER  BOTH  ERRORS.  ERRORS 
ARE  ASSUMED  TO  BE  100  PERCENT  CORRELATED  (WORST  CONDITION). 


4.7  TELEMETRY  REQUIREMENTS 


4.7.1  Telemetry  Support.  The  requirements  for  the  acquisition  of 
telemetry  data  at  the  SCF  stations  are  as  follows. 

4. 7. 1.1  Launch  Phase.  There  are  no  requirements  for  direct  tele- 
metry support  through  deployment  of  the  IUS  from  the  Shuttle.  In- 
direct support  will  be  achieved  via  the  Shuttle  avionics. 

4. 7. 1.2  Drift  Orbit.  A TBD-minute  sample  of  telemetry  data  is  to 
be  recorded  by  the  SCF  in  the  general  telemetry  mode  (paragraph 
4.7.4)  every  TBD  hours  up  to  initial  injection  into  the  final  orbit 
or  deployment  of  the  payload  satellite (s) . 

4. 7. 1.3  Stationing  On-Orbit.  Continuous  telemetry  coverage  is  re- 
quired during  all  commanding  in  order  to  arrest  and  trim  drift- 
orbit  velocity  for  station  positioning  on-orbit. 

4. 7. 1.4  Attitude/Orbit  Maneuvers 

A.  Continuous  telemetry  coverage  by  the  SCF  is  required  during 
all  orbit  and/or  attitude  maneuver  from  TBD  minutes  prior  to 
the  first  command  through  TBD  minutes  after  the  final  com- 
mand . 

B.  A TBD  sample  of  telemetry  data  (general  mode)  is  required 
TBD  seconds  following  each  attitude/orbit  maneuver. 

4. 7. 1.5  Recording  Requirements.  All  telemetry  data  received  at 
the  STC  from  first  acquisition  until  end  of  mission  will  be  retained 
for  a period  of  TBD  at  the  STC  on  magnetic  tape.  The  IUS  downlink 
data  rate  is  in  accordance  with  standard  SGLS.  During  this  TBD 
period  the  systems  program  office  (SPO)  may  request  data  printed 
out  in  various  modes. 

Recording  equipment  shall  not  add  errors  to  the  data  stream  at  a 
rate  greater  than  TBD  when  measured  at  the  recorder  output  for  re- 
produced data,  referenced  to  error-free  recorder  input  data. 

The  telemetry  report  format  is  TBD. 


4.7.1 


1.7.2  Description  of  the  Telemetry  List.  The  description  of  the 
telemetry  list,  including  explanation  of  column  headings  and  sort- 
ing technique,  will  be  specified  for  individual  missions. 

4.7.3  Telemetry  Modes.  The  number  and  type  of  telemetry  modes  are 
miss  ion- peculiar . 

4.7.4  Telemetry  Mode  Format.  All  telemetry  modes  will  be  designed 
for  printing  in  the  same  general  format.  The  specifics  of  this 
format  are  TBD. 


4.8  CONTROL  AND  DISPLAY  REQUIREMENTS 

4.8.1  SMCC  Control  and  Display  (CfiD) . Displays  are  required  at 
the  SMCC  for  Technical  Advisor  use  to  display  the  TLM  data  as 
specified  in  paragraph  4.7.  These  displays  will  be  required 
throughout  the  entire  mission.  Other  C5D  requirements  are  TBD. 


4.9  COMMANDING  REQUIREMENTS 

4.9.1  Command  Process  Requirement 


4. 9. 1.1  General  Command  Operations.  Command  to  the  IUS  will  be 
generated  by  the  SMCC.  Command  transmission  to  the  IUS  is  via  the 
SGLS  which  may  be  secure,  if  required.  The  authority  to  transmit 
types  of  commands  is  detailed  in  paragraph  4. 9. 1.3. 

Single  or  block  commands  will  be  transmitted.  The  receipt  of  com- 
mands by  the  IUS  will  be  verified  by  telemetry  data  prior  to  the 
transmission  of  subsequent  commands.  Alarms  occurring  during  com- 
mand transmissions  must  be  investigated  and  analyzed  as  to  possible 
effects  on  IUS  operation  prior  to  transmitting  subsequent  commands. 
At  the  end  of  each  command  operation,  the  RTS  will  forward  to  the 
Shuttle  Mission  Control  Center  (SMCC)  a summary  of  the  commands 
transmitted  to  the  IUS. 

4.9. 1.2  SCF  Support.  The  IUS  will  be  supported  by  the  SCF  in  the 
following  manner: 

A.  Command  Sources.  Commands  which  will  be  sent  to  the  IUS  by 
the  RTS  may  emanate  from  either  the  command  program  calcula- 
tions under  the  control  of  the  mission  controller  or  from  a 
procedure  available  to  the  test  controller. 

B.  Time-Tagged  Commands.  Commands  sent  to  the  IUS  may  be  time 
tagged.  The  RTS  will  comply  with  the  time-tag  on  the  com- 
mands within  TBD  seconds. 

4. 9. 1.3  Command  Authorization.  The  authorization  of  commands  prior 
to  transmission  to  the  IUS  will  be  vested  in  user  agencies,  which 
will  work  through  the  SMCC. 

4.9.2  Command  Description.  Detailed  requirements  imposed  upon  the 
SCF  for  IUS  commanding  clearly  must  be  delayed  until  the  IUS  vehicle 
is  defined;  since  the  vehicle  is  still  in  the  conceptual  stage  as  of 
the  initial  issue  date  of  this  document,  all  such  command  require- 
ments are  necessarily  TBD.  Specifications  will  eventually  evolve 
for  commanding  IUS  subsystems  by  SCF  ground  stations,  as  follows: 

• Communications  Subsystems 

• Control  Subsystem 
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• Electrical  Power  Subsystem 

• TT§C  Subsystem 

• Electrical  Distribution  System 

• Structures  Subsystem 

• Propulsion  Subsystem 

• Thermal  Control  Subsystem 

• Satellite  Separation  Subsystem 
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4.10  DATA  HANDLING  AND  DATA  DISTRIBUTION  REQUIREMENTS 

The  data  required  by  the  SCF  during  operational  mission  consists 
primarily  of : 

• Ephemeris 

• Data  base 

• IUS  status  reports 

• IUS  telemetry  printouts 

• Command  program  data  printouts 

• Command  summary 

• KSC  reports 

Distribution  of  each  of  the  above  items  is  listed  in  tables  4.10-1 
and  4.10-2, 
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DISTRIBUTION  OF  KSC  GENERATED  DATA 
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4.11  COMPUTER  PROGRAM  DEVELOPMENT 


4.11.1  Scope.  The  IUS  contractor  will  develop  a computer  program 
to  support  IUS  operation  associated  with  attitude  determination 
and  correction,  station  acquisition  and  maintenance,  and  the  plan- 
ning and  command  generation  necessary  for  accomplishing  these  opera- 
tions. The  program  will  be  written  in  TBD  language  for  use  on  a TBD 
computer  in  the  standard  configuration  and  software  environment  and 
shall  be  compatible  with  Launch  Processing  System  (LPS)  processors 
as  well  as  SCF  processing  systems. 

4.11.2  Command  Program  Functions.  The  program  will  support  and/or 
conduct  the  following  functions  and  the  executive  control  thereof: 

• Attitude  determination 

• Attitude  maneuver  command  data  generation 

• Orbital  maneuver  planning  and  command  data  generation 

• Retrieval  maneuvers  and  safing  command  data  generation 

• Telemetry  data  processing  relevant  to  the  above. 

The  general  performance  capabilities  applicable  tc  subprograms  of 
the  program  are: 

A.  Present  summary  data  for  online  decision  control,  with  pro- 
vision for  outputting  detailed  data  (normally  preserved  for 
offline  listing  and  analysis),  preselectable  by  user  option. 
In  general,  online  output  data  will  include  information  re- 
quired to  facilitate  validity  evaluations  and  performance 
assessments  by  user  personnel. 

B.  Provide  the  optional  capability  to  override  (but  not  replace) 
control  and  state  parameters  in  the  data  base  by  means  of 
function  card  input. 

C.  Format  the  command  sequences  both  for  manual  validity,  check- 
ing at  the  SMCC  and  for  transmission  to  the  RTS's  and  Shuttle 
for  command  backup.  These  command  sequences  will  include 
commands  for  preconditioning  the  vehicle  and  time  tags  for 
time-critical  commands  when  applicable. 
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D.  Interface  with  STS  Orbit  Ephemeris  System  functions,  pro- 
cedures and/or  subroutines  for  IUS  ephemeris  data  and  orbital 
prediction. 

4.11.3  Milestone  Schedule.  The  milestone  schedule  for  the  command 
program  software  is  illustrated  in  table  4.11-1.  Also  included  is 
a milestone  schedule  for  Model  TBD  software  at  the  SCF  which  is  re- 
quired to  support  the  program. 
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COMMAND  PROGRAM  MODELS  AND  SCHEDULE 


4.11.3 


4.12  TIMING  REQUIREMENTS 


The  standard  SCF  timing  system  which  measures  time  of  day  in  total 
seconds  is  required  on  all  printouts  and  command  summary  printouts. 
Time  is  referenced  to  GMT.  Telemetry  printout  data  lines  will  be 
time  tagged  to  the  nearest  whole  second  at  the  start  of  the  data 
frame.  Command  summary  printouts  will  be  time-tagged  to  the  near- 
est whole  second  at  the  initiation  of  the  transmission  of  the  com- 
mand word. 

Command  Program  data  printouts  require  the  time  of  calculated  com- 
mands measured  by  year,  month,  day,  hour,  minute  and  seconds  (GMT). 
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4.13  COMMUNICATIONS  REQUIREMENTS 

The  following  communications  links  are  required  for  IUS  operations: 

A.  Wideband  data  links  between  the  STC/SMCC  and  *the  RTS's.  IUS 
operations  require  a downlink  for  a data  rate  of  16  kb/s  and 
uplink  data  rate  (commands)  of  1 or  2 kilobauds. 

B.  Data  links  between  STC/SMCC  and  the  RTS's  for  the  transmis- 
sion of  prepass  data  commands,  antenna  pointing  data  and 
ranging  data. 

C.  Voice  an'  teletypewriter  links  between  the  STC/SMCC  and  the 
RTS's  for  control,  coordination  and  administrative  functions. 

D.  Circuits  described  in  a,  b and  c between  the  STC  and  KSC 
for  launch  coordination. 
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4.14  FACILITIES  REQUIREMENTS 


The  following  additional  facilities  will  be  required  for  IUS  opera- 
tions : 

TRD 
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4.15  OTHER  REQUIREMENTS 

4.15.1  STC/SMCC  Reports.  TBD 

4.15.2  Data  Base.  The  STC/SMCC  shall  provide  a data  base  in  sup- 
port of  IUS  scheduling  and  acquisition  times.  The  information  in 
the  data  base  will  be  supplied  for  each  mission  via  magnetic  tape. 

The  required  data  to  be  provided  for  each  mission  data  base  includes: 

• Ground  trace  table 

• RTS  acquisition  table 

• Events  tables 

Rise  and  fade  times  (5°  elevation  points)  for  each  RTS 
Shuttle,  IUS  and  payload  conjunctions 

• Orbital  elements  (ADBARV  format  may  be  specified) 

The  following  descriptions  provide  specific  definition  of  require- 
ments for  data  derived  from  IUS  ephemerides : 

TBD 
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